From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 118479 invoked by alias); 3 Apr 2019 20:25:07 -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 118458 invoked by uid 89); 3 Apr 2019 20:25:05 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=reaction, digging, trial, supplied X-HELO: mailsec108.isp.belgacom.be Received: from mailsec108.isp.belgacom.be (HELO mailsec108.isp.belgacom.be) (195.238.20.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Apr 2019 20:25:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=skynet.be; i=@skynet.be; q=dns/txt; s=securemail; t=1554323101; x=1585859101; h=message-id:subject:from:to:cc:date:in-reply-to: references:mime-version:content-transfer-encoding; bh=KTSCBapef/z/WEmnfaNZkFasXdJ6ELK6FiHYbZdN0SA=; b=H3nuN+wvYJdOnckoznP55gvLZuFZfKhS5E3Y/mnbVcGALXiR9XMujDka 3trkL8SaVfmngRq867/c9DnDVB/2fw==; Received: from 212.135-131-109.adsl-dyn.isp.belgacom.be (HELO md) ([109.131.135.212]) by relay.skynet.be with ESMTP/TLS/AES256-GCM-SHA384; 03 Apr 2019 22:24:57 +0200 Message-ID: <1554323097.1854.9.camel@skynet.be> Subject: PING Re: [RFC] Have an option to tell GDB to detect and possibly handle mismatched exec-files. From: Philippe Waroquiers To: Tom Tromey , Pedro Alves , jan.kratochvil@redhat.com Cc: gdb-patches@sourceware.org Date: Wed, 03 Apr 2019 20:25:00 -0000 In-Reply-To: <1553106871.6197.31.camel@skynet.be> References: <20190318225822.4820-1-philippe.waroquiers@skynet.be> <87ef72x1a4.fsf@tromey.com> <1553106871.6197.31.camel@skynet.be> Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00062.txt.bz2 Pedro/Jan, Some feedback ? Thanks Philippe On Wed, 2019-03-20 at 19:34 +0100, Philippe Waroquiers wrote: > On Tue, 2019-03-19 at 10:43 -0600, Tom Tromey wrote: > > > > > > > "Philippe" == Philippe Waroquiers writes: > > > > Philippe> A recurrent problem with GDB is that GDB uses the wrong exec-file > > Philippe> when using the attach/detach commands sucessfully. > > Philippe> Also, in case the user specifies a file on the command line but attaches > > Philippe> to the wrong PID, this error is not made visible and gives a not user > > Philippe> understandable behaviour. > > > > I've been bitten any number of times by this. So, it would be great to > > have this fixed. > > > > Philippe> There was a previous trial to fix this PR. > > Philippe> See https://sourceware.org/ml/gdb-patches/2015-07/msg00118.html > > Philippe> This trial was however only fixing the problem for the automatically > > Philippe> determined executable files when doing attach. > > I have re-read all the exchanges for the above fix trial. > It ended up with the above msg00118 with Pedro asking 'WDYT?', > and it looks like everybody was thinking nothing. > So, after more than 4 years, here is some feedback :). > > IMO, the distinction between auto-discovered and user-specified > is artificial: if the user will debug a PID with what looks like a > wrong executable specified by the user, GDB should not silently > use the user provided file, as keeping it is very probably > wrong (at least in the cases I have seen, it was always me > doing an error, and the patch below will make the error visible > and easy to fix) : > The patch proposed below will indicate that there is very probably > something weird, and then the user can change the setting and/or > decide to not load the exec file discovered from the PID. > > Also, the patch above makes GDB unconditionally switch of exec file > for auto-discovered > files. > If ever the user really want to do something 'unusual', no way. > Again, the patch > below allows the user to control the behaviour > if really something unusual is > desired/needed. > > > > > There was also this series: > > > > https://sourceware.org/ml/gdb-patches/2014-03/msg00476.html > > > > ... which seemingly went through at least 4 rounds of review and then > > did not land for some reason. > > After digging in the mail archive, it looks like the last state > of this mail thread was the v5 done by Jan Kratochvil. > I found no reaction to this v5. No idea why it stalled. > > That being said, I think that this last series does something different. > IIUC, this patch series ensures that when GDB receives the pathname > of a file to use (typically from a gdbserver), that GDB will use the > build-id to decide to *not* load the debug info, but this does not > lead to 'switch' to another correct exec-file. > > In other words, this v5 ensures that GDB does not load wrong > debug info for a file GDB has decided to use as exec-file (or library). > It does not detect or report that a wrong file is selected for a PID. > > In that sense, the patch proposed below is not contradictory with this > last patch v5: once GDB has decided to use a certain exec-file, > GDB today checks e.g. that the file has not changed of time stamp > (otherwise it re-reads the file). As I understand, the build-id is just > a more sophisticated way to detect if the file loaded by the PID > is consistent with either the reported file to use by GDB and/or with > the separate debug info GDB finds on the host side. > > > > > Before approving anything I would like to understand why neither of > > these earlier attempts went in. > > > > The build-id approach is appealing because (especially since the demise > > of prelink) it seems that gdb could simply trust it and abandon > > non-matching symbol files, without needing a "user supplied" bit. > > In summary, I think that the patch below is another approach > than the 'sticky user executable' concept, but does not aim at > solving the problem of an exec-file or a remote exec-file > inconsistent with some GDB host debug info. > > > Philippe > > >