Re: Improving GDB for multicore and embedded system!

[Daniel Jacobowitz <drow@false.org>]

On Fri, Mar 02, 2007 at 03:20:43PM +0100, Fabian Cenedese wrote:
> We can stop any number of threads while the others continue to run
> (well, the comm-thread needs to run always or it's rather dull to watch :)
> I have once tried to map this onto the threads of gdb. That worked
> in so far, that I could get the info about all the threads. But as soon
> one was stopped gdb assumed that all we're stopped. So no refreshes
> anymore, wrong variable contents etc.

Yes, this is an entirely different embedded debugging problem.

> The other solution with one instance of gdb for every thread wasn't
> very liable either. The biggest images including debug info can be
> in the dozens of MB. After gdb has loaded such an image the
> memory consumption was in the range of 200MB. Multiply this
> with one or two dozen threads and you can imagine how long
> it would take to start debugging, not even speaking of the
> memory consumption...

The expedient hack would be to load the debugging image once, and then
fork off separate GDBs to control each target.  I don't know how much
trouble that would be to get to work.

> So I still follow the gdb list here and we would very welcome
> any improvements in this area (I know, gdb is open source, we
> could do it ourselves etc. Unfortunately neither manpower nor
> knowledge)

Yes.  Unfortunately, I have neither the time nor the urgent need, so
I'm not going to do it either :-)  I'll just keep hoping.

-- 
Daniel Jacobowitz
CodeSourcery