On 17 February 2011 17:23, David Madden <[email protected]> wrote: > On 02/17/2011 07:57 AM, Petr Hluzín wrote: > >> Actually this is a bug in simulavr. In file src/cmd/gdbserver.cpp in >> function GdbServer::gdb_read_memory(const char *pkt) change these >> lines: > > Thanks, Petr. (I had started looking at the GDB debugging output from > Simulavr, and it appeared that the problem was in there -- GDB was asking > for reasonable things, but the simulator was reporting things wrong. I was > going to start debugging Simulavr tonight.)
Also good! I am having good mood - I might do some work on simulavr during weekend. If you report some issues I will try to fix them. > I'll make your changes and see what happens. > >> Simulavr also eats 100% CPU when waiting for GDB. What a shame, I >> should fix that before anyone notices. :) (But I did not write the >> crappy function.) > > That would be great -- I had noticed that problem too, but I thought maybe > the simulator was in "Run" state except when GDB tells it to stop at a > breakpoint? But this sounds like a busy-waiting loop in the read() from > GDB. It should not burn CPU unless GDB is "executing" the program (i.e. waiting for a breakpoint to be hit). I am not sure about the modes when GDB is not connected. People, in what situations does simulavr "wait" for input when not controlled by GDB? > Who writes code like that? :-) Busy-waiting/polling is easy to write, needs no thinking ahead. F/OSS software usually starts because someone needs to scratch an itch. Simulavr can receive bytes from multiple TCP connections (gdb, value-change dumps, status display, perhaps more). That would need some sort of select() call and centralized dispatch. I plant to fix that. Folks, any objections or preferences how should I do that? (I think I will solve that myself, I must accommodate for Windows unusual sockets.) -- Petr Hluzin _______________________________________________ Simulavr-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/simulavr-devel
