Re: [Simulavr-devel] Connect with gdb to a core of a python simulation

[Petr Hluzín]

On 17 August 2011 23:49, Marek Pietrzak <address@hidden> wrote:
> I'm afraid Petr is right and current design doesn't support multiple gdb
> servers, or I do something wrong, anyway multiple instances for me lock
> one other.

GdbServer::Step() has a loop iterating over other servers (variable
GdbServer::allGdbServers ). Maybe I caused the lock-up when I fixed
CPU burning when waiting for GDB. If the loop did ever work then
simulavr must have been consuming 100% CPU in the loop.

It should be possible to move waiting for all TCP connection to a
central place. On linux we can use select(). It is more complicated on
Windows but I did some experiments in July and I think it is doable.

> Single core should be ok though. I can also imagine having a single gdb
> instance and cores as multiple threads in the execution.

I am almost sure the cores cannot be emulated as GDB threads - I
believe GDB requires all threads to share the same address space (i.e.
a byte at address 0x123 has to be the same for all threads). However
it should be possible to emulate multiple processes - user would have
to use "target extended-remote" and we would have to implement some
remote protocol commands. I have no experience with the protocol,
though.

On 18 August 2011 06:41, ThomasK <address@hidden> wrote:
> And on the other hand: if you debug simulavr with multicore then you
> stop the time for all cores and all hardware instances!

I think it is a desired behavior to stop all cores.
* User may need to investigate the other cores for clues (running them
would destroy the evidence)
* the other cores may depend on the debugged core and fail (or
influence their state) if they do not get response from the core
making their debugging harder
* user probably wants to examine the debugged core, not to interact
with other cores
Gdb probably does have means allowing user to selectively unfreeze processes.

-- 
Petr Hluzin