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

[Pedro Alves <palves@redhat.com>]

On 9/7/19 12:19 PM, Philippe Waroquiers wrote:
> Patch is a nice target :).
> This can be useful e.g. with the valgrind gdbserver, that only
> supports to debug a single process (i.e. the valgrind process that
> runs its embedded gdbserver).

Ahah, yeah, this was one of potential use cases for the multi-target work
that I talked about in last year's cauldron (in the multicore bof).

https://gcc.gnu.org/wiki/cauldron2018?action=AttachFile&do=get&target=palves-TheMulticoreGDBBoF%282018%29.pdf

> 
> First, a minor suggestion about the terminology (as introduced in patch 17, and used
> in command names): the rational is that 'target' being already overloaded,
> the wording 'target connection' is used  (leading to e.g. the command
> 'info connections').
> I am wondering if the word "connection" is not also too overloaded,
> and too much interpreted as meaning 'a real connection', which might lead to
> some user confusion.
> 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.

I'm already used to saying / hearing "open a connection to some target",
so I thought it was natural.  E.g., we have this command already:

 (gdb) help set auto-connect-native-target 
 Set whether GDB may automatically connect to the native target.
 When on, and GDB is not connected to a target yet, GDB
 attempts "run" and other commands with the native target.

Granted, I was the one who invented/added that command and
wrote that text.

But see the much older "target" command:

(gdb) help target 
Connect to a target machine or process.
^^^^^^^
The first argument is the type or protocol of the target machine.
Remaining arguments are interpreted by the target protocol.  For more
information on the arguments for a particular protocol, type
`help target ' followed by the protocol name.


Also, we have the "disconnect" command, with "disconnect" obviously
being the opposite of "connect", meaning close a connection:

 (gdb) target native 
 Done.  Use the "run" command to start a process.
 (gdb) maintenance print target-stack 
 The current target stack is:
   - native (Native process)
   - None (None)
 (gdb) disconnect 
 (gdb) maintenance print target-stack 
 The current target stack is:
   - None (None)

I'm thinking that it would be natural to use that
command to stop debugging a core dump too, for example,
I think this should be made to work:

 (gdb) core core.10872 
 ...
 Program terminated with signal SIGSEGV, Segmentation fault.
 #0  0x00007f176838d3e7 in ?? ()
 [Current thread is 1 (LWP 10872)]
 (gdb) maint print target-stack 
 The current target stack is:
   - core (Local core dump file)
   - None (None)
 (gdb) disconnect 
 You can't do that when your target is `core'
 (gdb) 

> 
> Otherwise, I did a minimal test to see how GDB could connect to 2 different
> valgrind gdbservers (a 64 bits and a 32 bits), but I could not make it work.
> The 2 valgrind I have launched are (in the top of a valgrind build):
> 
> ./path to/bin/valgrind --vgdb-error=0 ./memcheck/tests/trivialleak 
> ./path to/bin/valgrind --vgdb-error=0 ./memcheck/tests/x86-linux/scalar_exit_group
> 
> (gdb) tar rem|lvgdb
> Remote debugging using |lvgdb
> ...
> (gdb) add-inferior -no-connection
> [New inferior 2]
> Added inferior 2
> (gdb) tar rem |lvgdb --pid=16727
> Remote debugging using |lvgdb --pid=16727
> ...
> (gdb) info connection
>   Num  Name                      Description       
>   1    remote lvgdb              Remote serial target in gdb-specific protocol 
> * 2    remote lvgdb --pid=16727  Remote serial target in gdb-specific protocol 
> (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?

> (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.

Was this with "set schedule-multiple" set to "on", or "off", BTW?

> 
> 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.
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Here's that WIP patchset in question:

 https://github.com/palves/gdb/commits/palves/filename-options

Thanks,
Pedro Alves