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

[Philippe Waroquiers <philippe.waroquiers@skynet.be>]

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