From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118807 invoked by alias); 8 Sep 2019 20:50:29 -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 118795 invoked by uid 89); 8 Sep 2019 20:50:29 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.3 required=5.0 tests=AWL,BAYES_50,KAM_ASCII_DIVIDERS,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=no version=3.3.1 spammy=channels, HTo:U*palves, trunk_untouched, internal-error X-HELO: mailsec118.isp.belgacom.be Received: from mailsec118.isp.belgacom.be (HELO mailsec118.isp.belgacom.be) (195.238.20.114) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 08 Sep 2019 20:50:26 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1567975826; x=1599511826; h=message-id:subject:from:to:date:in-reply-to:references: mime-version:content-transfer-encoding; bh=/+uF8jGWyuG0VnEqEcYhk38OTdAwgBpHK+wS/kCBI0k=; b=ssN1VLZuUKtWHuOS9ZKGNzoJ4K0DQiKDOl8RNkr44Tayn/acKVcuQ2jn zuIYVUjN911PlVgLBNyk58v7l+RVBA==; Received: from 255.38-242-81.adsl-dyn.isp.belgacom.be (HELO md) ([81.242.38.255]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 08 Sep 2019 22:50:23 +0200 Message-ID: <6c1828abbbfda76da123926fda8b37816132075a.camel@skynet.be> Subject: Re: [PATCH 00/23] Multi-target support From: Philippe Waroquiers To: Pedro Alves , gdb-patches@sourceware.org Date: Sun, 08 Sep 2019 20:50:00 -0000 In-Reply-To: <6bed10d6-482f-917d-54f5-34c079ee9547@redhat.com> References: <20190906232807.6191-1-palves@redhat.com> <2802fb1954a3756ec7e507141652b8d92127424a.camel@skynet.be> <6bed10d6-482f-917d-54f5-34c079ee9547@redhat.com> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.30.5-1.1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00126.txt.bz2 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 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