From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129888 invoked by alias); 8 Sep 2019 20:06:30 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 129879 invoked by uid 89); 8 Sep 2019 20:06:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=1.6 required=5.0 tests=BAYES_50,KAM_ASCII_DIVIDERS,KAM_SHORT,SPF_HELO_PASS autolearn=no version=3.3.1 spammy=year's, channels, meaning, embedded X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 08 Sep 2019 20:06:27 +0000 Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 64C10C0546F1 for ; Sun, 8 Sep 2019 20:06:26 +0000 (UTC) Received: by mail-wr1-f70.google.com with SMTP id j10so5964132wrb.16 for ; Sun, 08 Sep 2019 13:06:26 -0700 (PDT) Received: from ?IPv6:2001:8a0:f913:f700:4eeb:42ff:feef:f164? ([2001:8a0:f913:f700:4eeb:42ff:feef:f164]) by smtp.gmail.com with ESMTPSA id 189sm15637948wmz.19.2019.09.08.13.06.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Sep 2019 13:06:24 -0700 (PDT) Subject: Re: [PATCH 00/23] Multi-target support To: Philippe Waroquiers , gdb-patches@sourceware.org References: <20190906232807.6191-1-palves@redhat.com> <2802fb1954a3756ec7e507141652b8d92127424a.camel@skynet.be> From: Pedro Alves Message-ID: <6bed10d6-482f-917d-54f5-34c079ee9547@redhat.com> Date: Sun, 08 Sep 2019 20:06:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <2802fb1954a3756ec7e507141652b8d92127424a.camel@skynet.be> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2019-09/txt/msg00125.txt.bz2 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