This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Improving GDB for multicore and embedded system!
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