Debugging Multiple Inferiors

Debugging Multiple Inferiors

[florent vion]

Hi the experts,

Do you know if it is possible to debug two cortex-m in parallel with
one gdb session using inferiors?
Do I need to enable the non stop mode if I use the remote protocol?

Here my tests so far:
  (gdb) target remote :3333
  (gdb) file cortex1.elf
  (gdb) load cortex1.elf

  (gdb) add-inferior
  (gdb) inferior 2
  (gdb) maint info program-spaces
    Id   Executable
    1    cortex1.elf
         Bound inferiors: ID 1 (Remote target)
    * 2
         Bound inferiors: ID 2 (process 0)
  (gdb) target remote :3334
  A program is being debugged already.  Kill it? (y or n) y
  /home/.../gcc-arm/src/gdb/gdb/thread.c:639: internal-error:
thread_info* any_thread_of_process(int): Assertion `pid != 0' failed.
  A problem internal to GDB has been detected,
  further debugging may prove unreliable.
  Quit this debugging session? (y or n)

It seems that the remote target behaves as an Highlander, "there can
be only one"...

Regards,
Florent

Re: Debugging Multiple Inferiors

[Pedro Alves]

On 09/07/2017 01:09 PM, florent vion wrote:
> Hi the experts,
> 
> Do you know if it is possible to debug two cortex-m in parallel with
> one gdb session using inferiors?

Interesting!  And apropos too.  If possible, I'd love to
hear more about the use case.

It's not possible today, but hopefully that won't be for too long.
See below.

> Do I need to enable the non stop mode if I use the remote protocol?

...

> It seems that the remote target behaves as an Highlander, "there can
> be only one"...

Indeed.  However, I've actually been working on lifting
that limitation.

You can find my WIP branch here:

  https://github.com/palves/gdb/commits/palves/multi-target

It's a WIP, still with a couple of quick hacks in place, but
it's good enough to debug multiple remote connections at the
same time using that, provided the remote stubs support the
same set of remote protocol extensions (which is not an
issue if you have two exactly equal boards) and provided
the remote target/stub supports non-stop mode.  If you want
to give it a try, know that user-visible all-stop mode does
work, however you'll need to do "maint set target-non-stop on"
before connecting to force the remote connection itself
to use non-stop mode.

I've been focusing on "target extended-remote" (+ "run"), but
I expect that "target remote" should work too.  (If it doesn't
yet, I'll want to fix it.)

FYI, if you're curious about implementation details, earlier
attempts at multi-target are described here:

  https://sourceware.org/gdb/wiki/MultiTarget

While my new implementation is different/new, a good part
of the info on that page is still relevant, since it lists
the problem that need to be addressed.  Perhaps the main
difference in my approach is that nowadays GDB is a C++ program
and I'm making target_ops a C++ class hierarchy, and that
I'm not extending PTID, but instead making core of gdb use
thread_info/inferior/target_ops pointers more.

Thanks,
Pedro Alves