Re: [PATCH 00/23] Multi-target support

Philippe Waroquiers
2019-09-08T20:50:29Z

On Sun, 2019-09-08 at 21:06 +0100, Pedro Alves wrote:
> Maybe other wording could be used instead (such as 'target channel'
> > and 'info channels') ? Or maybe another synonym of channel or similar ?
>
> Hmm, I'm not seeing how those would be an improvement over connection,
> to be honest.
Ok, the rational to use connection is convincing.

> (gdb) b main
> > Breakpoint 1 at 0x109168: main. (2 locations)
> > ????? this has put a break at 2 locations in 2 different inferiors, reporting
> > only one address. Wondering if that is the expected
> > behaviour. In any case, that behaviour does not look to be a big deal.
>
> Yeah, this behavior shouldn't have changed with this patchset. You should
> see the exact same if you were debugging the two inferiors under the
> same target. Does it differ for you? You have two locations, because
> we create one location per inferior. I don't recall offhand why we only
> show one address -- maybe the address is the same for all locations?
When using 2 native inferiors, one 64 bit and one 32 bits, origin/master gives:
(gdb) b main
Breakpoint 1 at 0x1168: main. (2 locations)
(gdb) info bre
Num Type Disp Enb Address What
1 breakpoint keep y <MULTIPLE>
1.1 y 0x0000000000001168 in main at trivialleak.c:12 inf 1
1.2 y 0x000011d6 in main at scalar_exit_group.c:6 inf 2
(gdb)

But I did some other tests with Ada generics and c++ templates,
and this all shows only one address, while multiple breakpoints have
been set at different addresses.
So, the behaviour with multi-target is normal.

>
> > (gdb) infer 1
> > [Switching to inferior 1 [Remote target]
> > (/home/philippe/valgrind/git/trunk_untouched/memcheck/tests/trivialleak)]
> > [Switching to thread 1.1 (Thread 10050)]
> > #0 0x0000000004001090 in _start () from /lib64/ld-linux-x86-64.so.2
> > (gdb) c
> > Continuing.
> > Connection 2 (remote lvgdb --pid=16727) does not support multi-target resumption.
> > (gdb)
> >
> > So, the continue command is refused both in inferior 1 and inferior 2.
>
> Does valgrind's gdbserver support non-stop mode? I thought it didn't,
> but if it does, then you need to do "maint set target-non-stop on"
> before connecting. This is one of the limitations that I described
> in patch #17.
valgrind gdbserver does not support non-stop mode.
>
> Was this with "set schedule-multiple" set to "on", or "off", BTW?
I just tried with both values, and neither of them allow to continue.
So, with multiple valgrind gdbserver targets, I have not seen how to continue
execution.

>
> > Then when stopping this gdb (which automatically continues the valgrind executables
> > till valgrind reports the next error), launching a new gdb, and only connecting to the 32
> > bits valgrind gdbserver, here is what I see.
> >
> > (gdb) tar rem|lvgdb --pid=16727
> > Remote debugging using |lvgdb
> > ...
> > 0x04001092 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> > (gdb) bt
> > #0 0x04001092 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
> > #1 0x0495fd27 in syscall () at ../sysdeps/unix/sysv/linux/i386/syscall.S:29
> > #2 0x0010922c in main () at scalar_exit_group.c:14
> > (gdb) c
> > Continuing.
> > ../../multi-target-v1/gdb/inferior.c:285: internal-error: inferior*
> > find_inferior_pid(process_stratum_target*, 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)
> >
> > So, that looks to be a regression with the valgrind gdbserver.
>
> Thanks. I'll have to try reproducing this.
>
> > I did another trial using an abbreviation for -no-connection, but then
> > that does not work:
> > (gdb) add-inferior -no-connection
> > [New inferior 2]
> > Added inferior 2
> > (gdb) add-inferior -no-conn
> > [New inferior 3]
> > Added inferior 3 on connection 1 (remote lvgdb --pid=17046)
> > (gdb)
> >
> > Maybe add-inferior should better be converted to the option framework ?
>
> Right, here's what I said in patch #17 about this:
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> I tried converting "add-inferior" to the gdb::option framework, as a
> preparatory patch, but that stumbled on the fact that gdb::option does
> not support file options yet, for "add-inferior -exec". I have a WIP
> patchset that adds that, but it's not a trivial patch, mainly due to
> need to integrate readline's filename completion, so I deferred that
> to some other time.
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Ouch, missed that.
What created the surprise is that add-inferior does not use
something like:
strncmp (opt.get (), "-someoption", strlen (opt.get ())

Thanks

Philippe