Re: Improving GDB for multicore and embedded system!

[Paul Koning <pkoning@equallogic.com>]

I have some experience with multicore debugging and hacking GDB for
that.

In our case, we have two cores that have the same instruction
architecture.  But they are running different OS, and one is running
64-bit code while the other is running 32-bit.

For live debug, we use two copies of GDB.  Yes, that uses up some more
VM for the multiple symbol tables.  No problem, workstation memory is
cheap and easy to get.  Each core has a stub, so we can do remote
debug via its stub.  (If they had to share a stub, which may happen at
some point, I'll probably just put in a mux widget that continues to
create the appearance of separate stubs.)

For crash dump analysis, I get all of memory in a single dump file.
Debugging that with two GDBs would be possible but annoying, so I
added hacks to the dump analyzer machinery to allow it to switch
between the two OS views.  It switches address spaces (easy) and it
switches executable file symbol tables (very hard).  Fortunately, the
kernel doesn't have shared libs or the like, it's all one file.

This works just well enough to make it practical.  It does
occasionally mess up.  For dump analysis that's not too big a problem,
just restart GDB.  For live system debug that would create the risk of
losing control, which is one reason why we don't do it there.

If you have a situation where the multiple cores can be presented to
GDB as threads of a single image, the thread machinery should work.
If that model doesn't fit, I think the best way to proceed would be to
use multiple GDBs, and buy more PC DRAM if necessary.  That would be
especially true if the various cores differ enough that a single GDB
doesn't understand all of them even after putting the multiarch
machinery to work.

The notion that you debug exactly one executable file seems to be very
much fundamental in GDB.  You can hack around it but the result is
messy and not very stable.  Or I suppose if you have enough help from
the GDB experts you can redesign GDB to eliminate this assumption.  I
don't know how long that would take and how hard it would be.
Personally, if I had a need for this kind of debug support, I'd just
use the multiple GDBs and ask the boss for more memory.

    paul