Re: [Simulavr-devel] [patch #7030] do not eat 100% CPU if GDB disconnects

[Petr Hluzín]

Hi Thomas

2010/1/6 ThomasK <address@hidden>:
> Hi Petr,
>
>> A free running simulation after exiting the gdb - is it desired behavior?
>
> Yes, that's the question! This feature is old, as I have seen in code. So I
> wouldn't remove this without the question: why and who needs this?

If the simulator is launched with --gdbserver and gdb connection is
(opened and) closed, the GdbServer::receive_and_process_packet()
returns GDB_RET_KILL_REQUEST to GdbServer::InternalStep(), which bails
out without doing without core->Step() or updating
timeToNextStepIn_ns.
Wait a minute... timeToNextStepIn_ns remains un-initialized at
GdbServer re-insertion test in SystemClock::Step(). If
timeToNextStepIn_ns is negative (my case) the GdbServer is removed.
But it is undefined in general.

My understanding: three use-cases for a simulator:
a) used for debugging by gdb
b) used for automated testing (of gcc or user's programs)
c) used for tinkering by some UI or electronics simulator ("online spice")

Mixed usage is rare/unusual/weird. Allowing it (without user
specifically asking for that) would mask problems or cause problems.
Like an simulator instance not willing to die, and even consuming CPU.

Perhaps if GDB quits without issuing "kill" then it could stay up and
without running the MCU.
Does someone know a situation where is helpful to quit GDB and keep
the MCU running?

Launching another simulator instance is cheap.
Oh, except it needs another TCP port number. This can be fixed. I can
fix that. And also connecting GDB via named FIFO so that user does not
have specify anything (if appropriate support is added to GDB).

> And, of course, usage of simulavr with gdb was the first intention to
> develop simulavr. Use simulavr with tcl or later python interface was
> implemented later. So the primary goal would be (in my opinion) to hold gdb
> support operational.

Agreed. See the use-case b) above.

> But there is a other question: if you want to simulate
> a multi avr processor environment (possible by tcl/python scripting
> interface) and then connect to one processor with gdb - how should be the
> behaviour there? Should the not connected processor run even if the
> connected processor is halted by gdb. Only one question from many. This
> needs some good ideas and a rewrite of gdb interface. (maybe one wants to
> debug not only one processor, this isn't possible now)

GDB 7.0 can now debug multiple "processes". This can be used for
multiple MCUs. I do not know GDB remote-protocol can implement this
now.

-- 
Petr Hluzin