This is the mail archive of the
mailing list for the GDB project.
Re: Improving GDB for multicore and embedded system!
At 08:54 02.03.2007 -0500, Daniel Jacobowitz wrote:
>On Fri, Mar 02, 2007 at 10:08:55AM +0100, Denis PILAT wrote:
>> Today multicore debugging means multiple instance of gdb running at the
>> same time. I don't know how possible it is to enhance gdb so that it can
>> handle multiple programs running on different architecture.
>> I guess Daniel should have a good vision on that.
>No one has ever convinced me that there's a good reason to do this,
>rather than wire up things like DSF to drive multiple GDB's, if the
>cores are not all running the same architecture and program image. If
>they are, we generally present them as threads, and that works very
Actually that's the most important reason why we DON'T use gdb now.
Because it can't cope with our embedded OS organization. We have
multiple threads in the embedded device which are completely
independent, so I should rather call them processes. The whole
system is built and linked (from C++) as one image, downloaded
and started, so the code and debug info is for all processes the same.
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.
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
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