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

[Marek Pietrzak]

Hi,
First I'm not sure if debugging multiple cores is really something
that's needed very often. If so, I think it's possible to see the cores
in the simulation logically as separate threads in one and only instance
of GDB. Here stopping one thread (core) would stop all other threads.
It's the consequence of clock concept in simulavr (and called freeze
mode debugging sometimes). Of course GdbServer class is not designed to
do that, but if we ever wanted to support that...

Marek

On Thu, 2011-08-18 at 06:41 +0200, ThomasK wrote:
> Hi guys,
> 
> just to give my 2 cents ... ;-)
> 
> I think, simulavr isn't able to fit to this plan with simulating 2 or 
> more avr cores in the same time (!) with gdb. I don't know, how to do 
> that with gdb - but that's not my topic. simulavr isn't designed to do that!
> 
> How multicore works: it's one (!) process on OS, we have a instance of a 
> "mother clock" queue and, if needed, some instances of avr cores. This 
> is to synchronize the timing the hardware instances - and a core is 
> derived of hardware class. Gdb class shrinks into this "mother clock" to 
> serve also gdb requests. If you run 2 gdb server instances, you'll get a 
> dead lock. And on the other hand: if you debug simulavr with multicore 
> then you stop the time for all cores and all hardware instances! If 
> there is a request from gdb to change the core inside one (!) 
> connection, then it's possible. But maybe not that, what you want: to 
> see with 2 gdb instances how the code is processed in the same time on, 
> for example, two cores.
> 
> So, extending simulavr.i will not help for this case, but maybe, if you 
> want to debug with gdb and to simulate some expected hardware around the 
> core with python. (for example, connect 2 pins from a port, connect a 
> external clock or such)
> 
> Now you could tell: let's start 2 processes (threads), every with his 
> own gdb server. Then you have to fullfill some tasks: as written below, 
> if you debug in single step or halt the core, then you have to stop also 
> other cores - time synchronisation. Next: I'm not sure, if simulavr is 
> thread save now - that's sometimes difficult to solve but strong 
> neccessary! And you should have in mind: if you stop by gdb, you stop 
> too all, what's simulated in this thread!
> 
> So, it's not impossible, but a lot of work from now! And then it's the 
> question: will this help you really for developing code? (for so much work)
> 
> Ok, that's from me ... :-) cu, Thomas
> 
> 
> 
> Am 15.08.2011 21:55, schrieb Sebastian:
> > Hi,
> > is it possible to connect with gdb to a core of a python simulation?
> >
> > Something like
> >          device = pysimulavr.AvrFactory.instance().makeDevice(mcu)
> >          device.Load(program)
> >          device.SetClockFreq(clock_setting)
> >          sim.Add(device)
> >     device.setPortForGDB(1212) # I'm looking for this function
> > which also works for simulations with multiple devices.
> >
> > Sebastian
> >
> >
> >
> > _______________________________________________
> > Simulavr-devel mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/simulavr-devel
> >
> >
> 
> _______________________________________________
> Simulavr-devel mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/simulavr-devel