From patchwork Wed Jan 8 15:48:47 2020 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Tankut Baris Aktemur X-Patchwork-Id: 37258 Received: (qmail 86822 invoked by alias); 8 Jan 2020 15:48:55 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 86741 invoked by uid 89); 8 Jan 2020 15:48:54 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-19.4 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_0, GIT_PATCH_1, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.1 spammy=gary, Gary, Commercial, December X-HELO: mga02.intel.com Received: from mga02.intel.com (HELO mga02.intel.com) (134.134.136.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 08 Jan 2020 15:48:52 +0000 Received: from fmsmga007.fm.intel.com ([10.253.24.52]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Jan 2020 07:48:49 -0800 Received: from orsmsx108.amr.corp.intel.com ([10.22.240.6]) by fmsmga007.fm.intel.com with ESMTP; 08 Jan 2020 07:48:49 -0800 Received: from orsmsx155.amr.corp.intel.com (10.22.240.21) by ORSMSX108.amr.corp.intel.com (10.22.240.6) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 07:48:49 -0800 Received: from ORSEDG001.ED.cps.intel.com (10.7.248.4) by ORSMSX155.amr.corp.intel.com (10.22.240.21) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 07:48:48 -0800 Received: from NAM04-CO1-obe.outbound.protection.outlook.com (104.47.45.59) by edgegateway.intel.com (134.134.137.100) with Microsoft SMTP Server (TLS) id 14.3.439.0; Wed, 8 Jan 2020 07:48:48 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=n7nopfLua0qhV76U6UjGgoONTOra6qxOkqe2HBSB0Gk48fcSMTY3SNE2CxdDR/7NRs9XHFY6BrvyMfx3TuOMKejWMdqpJylQ8aDiVEl71Qb6HQUu120Nh6zHYQAvukG0VAb6kje+xyZwO2fMLN3HfNe4jrpn30S1s+NBLFCRDJmCevVP222TgYb+tN5NP/j77EUjaEwTfaegHsVG1AFEzdc7hNy47qhYxtlsf/NjWvWwq51VpJbe1Du1XuqfbVCCdW68SKouHtiITqk1KE+ynSEeN8vQg0MhUCOUl89GJ2EA1A05y5LL8LSZHkmwjfyJ5Xbq31v2VfiLCZIEsYKZxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w2L5fubMijqckAq19e/RFT77EyZ7kUEWe9EoeoUGOoE=; b=Dq5t9iWx2xBPmP9AyfLyRmimCaTrusmauvLmNqFX2X9cM7d8Kk0CA28JL0gd20C1Mt4quIvZ8fbTa58qTmODZQZnxqKC17HavA8ed0PTj3pCNeqKnEHn2ThDwWIX3oiTWlmDOqwvfP/SBq9Q6cgOmfvOhJlEAbZ9nZayhcfLErXcqkfZoLCZrwKc77pgKuUofoYajtTNhLoYiUgjSmljR5Xowc9driefrW9F5Gjn9AYMpzwdK82sfMd4j4VdHaWflKuAg/SkRWRgrqQfP81JqA2Wpam7L6C/OVauj9sVrRr7gN48hxBnYY4B4Z9Qi+uQWdH6tTyIawnxwnI/HaQFBg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=intel.com; dmarc=pass action=none header.from=intel.com; dkim=pass header.d=intel.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=intel.onmicrosoft.com; s=selector2-intel-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=w2L5fubMijqckAq19e/RFT77EyZ7kUEWe9EoeoUGOoE=; b=uHf6HdkGwdi/EU679FNfM8kwhEB7hO5hsICe+XcOT4IYkZagSPBoBBWD7x5hxkD/XgN8hNGQ4JqurlDes5oEmFbDcIfWPRfOHqkAglRi2z6aAX3uaILg2oFHEYJg8dhRQKMmvmYCdbMn0OAW4EgFTIyORYT4cQDMISMR/sZ0Cug= Received: from BYAPR11MB3030.namprd11.prod.outlook.com (20.177.225.91) by BYAPR11MB2888.namprd11.prod.outlook.com (20.177.226.147) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2602.13; Wed, 8 Jan 2020 15:48:47 +0000 Received: from BYAPR11MB3030.namprd11.prod.outlook.com ([fe80::2c94:a4bd:2d9c:30b]) by BYAPR11MB3030.namprd11.prod.outlook.com ([fe80::2c94:a4bd:2d9c:30b%6]) with mapi id 15.20.2602.017; Wed, 8 Jan 2020 15:48:47 +0000 From: "Aktemur, Tankut Baris" To: Pedro Alves CC: "gdb-patches@sourceware.org" , "Paunovic, Aleksandar" Subject: RE: [PATCH] Switch the inferior too in switch_to_program_space_and_thread (Re: [PATCH v2 08/24] Introduce switch_to_inferior_no_thread) Date: Wed, 8 Jan 2020 15:48:47 +0000 Message-ID: References: <20191017225026.30496-1-palves@redhat.com> <20191017225026.30496-9-palves@redhat.com> <489c25ee-b0ae-6a17-65cc-32c5d7c652d2@redhat.com> In-Reply-To: <489c25ee-b0ae-6a17-65cc-32c5d7c652d2@redhat.com> authentication-results: spf=none (sender IP is ) smtp.mailfrom=tankut.baris.aktemur@intel.com; x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: txZWhp90YvaRV4Qivv1Rlzwl9oYXwBxTOrQBTft2HgUgY3bkbkbCiIGqbR/a5eTJPc1H5artNFbTbCdXhybSA7zt9i4xZNB5/t4McUmr1Ko= Return-Path: tankut.baris.aktemur@intel.com X-IsSubscribed: yes On Monday, December 23, 2019 8:30 PM, Pedro Alves wrote: > > On 12/20/19 6:50 PM, Pedro Alves wrote: > > > Oh wow, thanks much for this. You're right. I'm working on > > converting your example above to a testsuite testcase. > > Here it is. I'm putting this at the end of the series, after the > multi-target patches, because before multi-target, the test > fails -- GDB sends a spurious Hg0.0 packet to the remote side. > > From 839bb32983d8afb085eeec1ac6ca499f5bbd6244 Mon Sep 17 00:00:00 2001 > From: Aleksandar Paunovic > Date: Mon, 23 Dec 2019 18:04:32 +0000 > Subject: [PATCH] Switch the inferior too in switch_to_program_space_and_thread > > With multi-target, each inferior now has its own target connection. > The problem in switch_to_program_space_and_thread is that in the > current state GDB switches to "no thread" and also sets the program > space but because the inferior is not switched, potentially an > incorrect target remains selected. > > Here is a sample scenario that exploits this flow: > > On terminal 1, start a gdbserver on a program named foo: > > $ gdbserver :1234 ./foo > > On terminal 2, start gdb on a program named bar. Suppose foo and bar > are compiled from foo.c and bar.c. They are completely separate. So, > bar.c:2 has no meaning for foo. > > $ gdb -q ./bar > Reading symbols from ./bar... > (gdb) add-inferior > [New inferior 2] > Added inferior 2 > (gdb) inferior 2 > [Switching to inferior 2 [] ()] > (gdb) target remote :1234 > ... > (gdb) set debug remote 2 > (gdb) break bar.c:2 > Sending packet: $Hgp0.0#ad...Packet received: OK > Sending packet: $m5fa,12#f8...Packet received: E01 > Sending packet: $m5fa,1#c6...Packet received: E01 > Sending packet: $m5fb,3#c9...Packet received: E01 > Sending packet: $m5fe,1#ca...Packet received: E01 > Breakpoint 1 at 0x5fe: file bar.c, line 2. > (gdb) > > Here we have an unnecessary sending of the packets to the gdbserver. > > With this fix in progspace-and-thread.c, we'll get this: > > (gdb) break bar.c:2 > Breakpoint 1 at 0x5fe: file bar.c, line 2. > (gdb) > > Now there is no sending of the packets to gdbserver. > > gdb/ChangeLog: > yyyy-mm-dd Aleksandar Paunovic > Pedro Alves > > * progspace-and-thread.c (switch_to_program_space_and_thread): > Assert there's an inferior for PSPACE. Use > switch_to_inferior_no_thread to switch the inferior too. > > gdb/testsuite/ChangeLog: > yyyy-mm-dd Pedro Alves > > * gdb.server/bkpt-other-inferior.exp: New file. > --- > gdb/progspace-and-thread.c | 6 +- > gdb/testsuite/gdb.server/bkpt-other-inferior.exp | 93 ++++++++++++++++++++++++ > 2 files changed, 96 insertions(+), 3 deletions(-) > create mode 100644 gdb/testsuite/gdb.server/bkpt-other-inferior.exp > > diff --git a/gdb/progspace-and-thread.c b/gdb/progspace-and-thread.c > index 3c92b5c8e0..d51748035e 100644 > --- a/gdb/progspace-and-thread.c > +++ b/gdb/progspace-and-thread.c > @@ -25,8 +25,9 @@ void > switch_to_program_space_and_thread (program_space *pspace) > { > inferior *inf = find_inferior_for_program_space (pspace); > + gdb_assert (inf != nullptr); This creates failure in gdb.base/step-over-exit.exp. The problem is, a forked child terminates, and GDB tries to switch to the pspace of that no-longer-existing inferior through a remaining breakpoint location. Would it make sense to guard calls to `switch_to_program_space_and_thread` as below, for example? There are a handful other cases that can be guarded/skipped similarly. I'm not sure, though, if the problem is deeper and the calls to `switch_to_program_space_and_thread` for a non-existing inferior should have never occurred. That is, should the breakpoint locations of exited inferiors be cleaned up much earlier, before we come to this point? -Baris > - if (inf != NULL && inf->pid != 0) > + if (inf->pid != 0) > { > thread_info *tp = any_live_thread_of_inferior (inf); > > @@ -39,6 +40,5 @@ switch_to_program_space_and_thread (program_space *pspace) > } > } > > - switch_to_no_thread (); > - set_current_program_space (pspace); > + switch_to_inferior_no_thread (inf); > } Intel Deutschland GmbH Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany Tel: +49 89 99 8853-0, www.intel.de Managing Directors: Christin Eisenschmid, Gary Kershaw Chairperson of the Supervisory Board: Nicole Lau Registered Office: Munich Commercial Register: Amtsgericht Muenchen HRB 186928 diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c index 080e847de1..30af603c73 100644 --- a/gdb/breakpoint.c +++ b/gdb/breakpoint.c @@ -2879,6 +2879,9 @@ update_inserted_breakpoint_locations (void) if (!bl->inserted || !bl->needs_update) continue; + if (find_inferior_for_program_space (bl->pspace) == nullptr) + continue; + switch_to_program_space_and_thread (bl->pspace); /* For targets that support global breakpoints, there's no need