From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29707 invoked by alias); 29 Oct 2019 19:56:54 -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 29690 invoked by uid 89); 29 Oct 2019 19:56:53 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 spammy=landing X-HELO: us-smtp-delivery-1.mimecast.com Received: from us-smtp-2.mimecast.com (HELO us-smtp-delivery-1.mimecast.com) (205.139.110.61) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 29 Oct 2019 19:56:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1572379011; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9HQdERAqlW5HSn0SDGUCpr8oCCidSxX9l0ykyRaDO2M=; b=GxmsSHn4+yYdi4Koqj6fI1/ME7iKEL9YrW2leGyejgb01odqzyEjZ/wak+vNoYFf8OiZ8N GbIBm8up3oVZ7JT8m2+SWihxRDVegW5yL6/f0YjK6jBo+uk/Q+wfre/LLBy9mAoq2JqRsx aLfxetcDP5UHag8GocRWY/YE10/cW1c= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-252-QRI9tPfqNoS5TbK9tiiPlA-1; Tue, 29 Oct 2019 15:56:49 -0400 Received: by mail-wr1-f71.google.com with SMTP id h4so9106879wrx.15 for ; Tue, 29 Oct 2019 12:56:48 -0700 (PDT) Return-Path: Received: from ?IPv6:2001:8a0:f913:f700:56ee:75ff:fe8d:232b? ([2001:8a0:f913:f700:56ee:75ff:fe8d:232b]) by smtp.gmail.com with ESMTPSA id 74sm19243155wrm.92.2019.10.29.12.56.46 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 29 Oct 2019 12:56:47 -0700 (PDT) Subject: Re: [PATCH v2 00/24] Multi-target support To: Philippe Waroquiers , gdb-patches@sourceware.org References: <20191017225026.30496-1-palves@redhat.com> <0deb38a1bee181cdcd6689d69ea69913f136f979.camel@skynet.be> From: Pedro Alves Message-ID: <694cad59-bec4-db00-5d2a-e725565f0d24@redhat.com> Date: Tue, 29 Oct 2019 19:56: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: <0deb38a1bee181cdcd6689d69ea69913f136f979.camel@skynet.be> X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-10/txt/msg01052.txt.bz2 On 10/20/19 12:41 PM, Philippe Waroquiers wrote: > I played a little bit with the patch and valgrind > (I had to apply the patch with git am --3way, otherwise it failed to appl= y). Guess you missed that this was in the users/palves/multi-target-v2 branch. = :-/ > No problem encountered when playing with the result. > I also re-read the documentation (as I forgot about how this was all > working), and it was all pretty clear. That's great to hear. >=20 > 3 notes: > * It might be interesting to one day add > something like 'inferior apply all/list of inferiors SOMMECOMMAND' Agreed. > * when having 2 inferiors connected to 2 different valgrind gdbservers, > I could continue both inferiors by using 'continue&', > but I had to (artificially) issue 'interrupt' in the second inferior > to have GDB accepting 'continue&'. So, this might be the indication > of a status 'running' which should be maintained per inferior, > while it might now be maintained globally. I've tried to debug this a little, but I'd like to punt for now. The error I'm seeing first comes from a breakpoint re-set, where gdb tries to read memory from the valgrind that is running. Breakpoint re-sets currently are too dumb and re-set all locations, instead of only adding/removing the locations necessary. And then that is running into the fact that the remote protocol in the old all-stop mode (which is what valgrind suppor= ts) is synchronous, gdb can't talk to the remote target until the target reports a stop. These sorts of issues is why I required that the remote backends support non-stop mode for this initial pass. I'd rather not have to fix all these issues before landing the initial multi-target support, even if we know there are issues we need to fix to make it cope better with all-stop-only targets. > * I was (again?) confused by add-inferior silently ignoring abbreviatio= ns > (or more generally anything starting with - unless matching exactly > an option). > Waiting for option framework to be extended, the add-inferior command > could use the below that accepts abbreviations and does not ignore > wrong options. Yes, that is fine with me. Thanks, Pedro Alves