Re: [Simulavr-devel] Re: [avr-gcc-list] simulavr-0.0.12 released

[Theodore A. Roth]

On Tue, 1 Jan 2002, address@hidden wrote:

:)On Mon, 31 Dec 2001, Theodore A. Roth wrote:
:)> I've applied this patch. From now on I'll always be doing my builds from a
:)> separate directory so I'll be able to catch lapses like this. I hadn't
:)> tested this feature of autoconf yet. I use it all the time for
:)> gcc/gdb/etc. I should have been using it before this point. Thanks for the 
:)> fix.
:)It was a pleasure to help you. Shall the html/pdf documentation get installed
:)anywhere? We could add a configure option for the path, where it shall be
:)installed. I think this could be usefull.

For docs, I think they should go here:
$PREFIX/share/doc/simulavr-$VERSION/

What's the Linux file system standard say on this?

:)
:)> The endless loop is inevitable since avr-gcc automagically adds a 
:)> while(1); like instruction after main() returns. There's really nothing 
:)> that can be done about it in simulavr.
:)I see no problem here. it is code generated by the compiler and it shouldn't 
be
:)changed.
:)
:)> I've had good luck with C-c in 
:)> simulavr to which _should_ sent gdb a reply indicating that a break 
:)> occured.
:)I have done this also, but as I described in my scenario, this is not how it
:)should be done, I think.

My solution was really just a cheap hack to aid my debugging. It can be 
changed.

:)
:)> gdb tends to not handle while(1); and for(;;); type constructs 
:)> very well. This is true of all arches, I tried it on a native linux 
:)> system, not pleasant.
:)I don't think, that gdb should do something. The source is as it is.
:)I think simulavr, should handle the break request from gdb. That's it. See my
:)last email with the suggestions about this issue.

Agreed.

:)
:)> I'll have to look into this some more. Try the extended remote protocol 
:)> for now and see what happens.
:)So you will continue to implement this part.
:)
:)Please correct me, but I think you have the same scenario for the work with
:)simulavr in mind than I have. If you would like to have me as a developer for
:)this project, than we need to define who does what in this project.

I'll leave the external interface to you for now. I think I've got enough 
to look into with other stuff for now.

:)
:)As you mentioned in an email before, you would like to finish the work on gdb
:)and the interface with simulavr. I have seen that there is a remote-sim 
backend
:)for gdb. Do you know when this shall be used? I have seen, that simulavr used
:)the real remote protocol and remote-sim.

When gdb talks about a sim, the simulator is actually linked into the gdb 
binary (either dynamically or statically). The sim interface is 
_extremely_ complicated. I just took the path of least resistance.

:)
:)I would like to investigate the interface to the outside world, because I need
:)this interface to simulate the hardware for my home automation sytem.
:)I don't know what the other people would like to do. Suggestions?
:)
:)> Thanks for the compliment. I've been working pretty hard on this for about 
:)> four months now and all the interest I've had lately is extremely 
:)> appreciated.
:)I hope we will make a big jump forward in the next weeks. I have to build my
:)house, when the snow is gone (currently it is realy cold in Vienna, it may 
take
:)a while) and I have a lot of work in my company, but I need my home automation
:)system ready in Q2/2002. So I need to spend a lot of sparetime for this 
project.

I think we can get a lot done soon.

Ted