[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Simulavr-devel] ATmega328 Emulation
From: |
Petr Hluzín |
Subject: |
Re: [Simulavr-devel] ATmega328 Emulation |
Date: |
Thu, 17 Feb 2011 22:24:37 +0100 |
On 17 February 2011 17:23, David Madden <address@hidden> 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