From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 111189 invoked by alias); 13 Sep 2019 22:52: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 111179 invoked by uid 89); 13 Sep 2019 22:52:30 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.8 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= 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; Fri, 13 Sep 2019 22:52:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathworks.com; s=mimecast20180117; t=1568415145; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=MyoIAW6Fmb/JmDNIbdb6XY8Yqe96yleqH1V4P8glHw8=; b=H3XrmxO6dw5jkNdW/6u+8QMegED92CQOxs5LwetyuQx26xRID/ga9nR4PiKOPjNCeKqOHc Qsj6hTWS29BhG2YXNQ2/f/GpGQ2uO+WO/wyNaQG8kuz9yd7dqke3Gk+i9rWWB9NNxj5Wp3 mnSaXcwBY2ZmA7M2dQZF1Ybdd2ki5IM= Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01lp2050.outbound.protection.outlook.com [104.47.32.50]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-56-32HW2TPtP4eE-Jk0Jhe8Bg-1; Fri, 13 Sep 2019 18:52:22 -0400 Received: from DM6PR05MB4156.namprd05.prod.outlook.com (20.176.72.29) by DM6PR05MB5307.namprd05.prod.outlook.com (20.176.119.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2241.7; Fri, 13 Sep 2019 22:52:20 +0000 Received: from DM6PR05MB4156.namprd05.prod.outlook.com ([fe80::a00e:ddad:be30:b632]) by DM6PR05MB4156.namprd05.prod.outlook.com ([fe80::a00e:ddad:be30:b632%6]) with mapi id 15.20.2263.016; Fri, 13 Sep 2019 22:52:20 +0000 From: Mike Gulick To: Andrew Burgess , Eli Zaretskii CC: Mike Gulick , "gdb-patches@sourceware.org" Subject: Re: [RFC] Apply compilation dir to source_path lookup Date: Fri, 13 Sep 2019 22:52:00 -0000 Message-ID: <82898bf2-3928-85a4-4f5f-cc9e194dd2a8@mathworks.com> References: <8058b501-9020-84f1-ecf4-b46bfe3b86e3@mathworks.com> <20190907235059.GN6076@embecosm.com> <4d9f4c81-8580-2b42-a434-389ed7655d7f@mathworks.com> <20190913013851.GT6076@embecosm.com> <835zlw1z45.fsf@gnu.org> <834l1g1wp7.fsf@gnu.org> <20190913224535.GX6076@embecosm.com> In-Reply-To: <20190913224535.GX6076@embecosm.com> x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:4941; x-ms-exchange-senderadcheck: 1 Content-ID: <4F3050D6B6988F4C83500054654CF592@namprd05.prod.outlook.com> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: vDj7No418v47TBE+Lm4pYSXvgHnutrFCmen9+5rnJ29LNNgXcFh4GIu+moPnjkAyW6IDBibjwxVEQQeMcmMx0g== X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-09/txt/msg00248.txt.bz2 On 9/13/19 6:45 PM, Andrew Burgess wrote: > * Eli Zaretskii [2019-09-13 10:28:52 +0300]: >=20 >>> Date: Fri, 13 Sep 2019 09:36:42 +0300 >>> From: Eli Zaretskii >>> CC: mgulick@mathworks.com, gdb-patches@sourceware.org >>> >>>> @value{GDBN} will also append the compilation >>>> +directory to the filename and check this against all other entries in >>>> +the source path. >>> >>> I think "append" here is a mistake. Should it be "prepend"? And >>> anyway, doesn't this simply repeat what was described in the text >>> above? >> >> Btw, do the "prepend" and "append", as implemented, take care to DTRT >> with Windows drive letters at the beginning of absolute file names? A >> literal prepending or appending will do the wrong thing there. You beat me to a response, but here's what I was going to say: The only way this would be a problem is if both the compilation directory and the source file contained a drive letter. I had assumed that if the debug information contained a compilation directory, then the file path would be relative to that. GCC at least seems to behave this way. [mgulick@mgulick-deb9-64:~/test/src] ... $ gcc -g -o test.o -fdebug-prefix-map=3D$HOME=3D -c test.c [mgulick@mgulick-deb9-64:~/test/src] ... $ dwarfdump test.o ... DW_AT_name test.c DW_AT_comp_dir /test/src ... [mgulick@mgulick-deb9-64:~/test/src] ... $ gcc -g -o test.o -fdebug-prefix-map=3D$HOME=3D -c `pwd`/test.c [mgulick@mgulick-deb9-64:~/test/src] ... $ dwarfdump test.o ... DW_AT_name /test/src/test.c ... In this case there is no DW_AT_comp_dir present. If you are concerned about this (possibly some crazy compiler emitting strange dwarf), the following change should suffice: diff --git a/gdb/source.c b/gdb/source.c index 1635563b20..3fd05a06f2 100644 --- a/gdb/source.c +++ b/gdb/source.c @@ -1049,8 +1049,12 @@ find_and_open_source (const char *filename, cdir_filename.pop_back (); /* Add our own directory separator. */ cdir_filename.append (SLASH_STRING); - /* Append filename, without any leading directory separators. */ + /* Append filename, without any leading directory separators or drive + names. */ const char * filename_start =3D filename; + /* For dos paths, d:/foo -> /foo, and d:foo -> foo. */ + if (HAS_DRIVE_SPEC (filename_start)) + filename_start =3D STRIP_DRIVE_SPEC (filename_start); while (IS_DIR_SEPARATOR (filename_start[0])) filename_start++; cdir_filename.append (filename_start); >=20 > Gah! >=20 > Looking at the implementation of 'openp' (in source.c) I see this > code: >=20 > /* For dos paths, d:/foo -> /foo, and d:foo -> foo. */ > if (HAS_DRIVE_SPEC (string)) > string =3D STRIP_DRIVE_SPEC (string); >=20 > which just seems to throw out the drive spec, and I can't find any > code that adds it back in. Is that going to do the right thing? >=20 > I did consider only creating the COMP_DIR/FILENAME combination if > FILENAME was not absolute, but I worried that this might be > unnecessarily restrictive, but now I'm tempted to say that would solve > this problem, and we should just wait until someone comes up with an > example where that is not good enough, before we figure out how to > allow it... This also seems fine to me. If FILENAME is absolute, there shouldn't be a compilation directory. >=20 > Thanks, > Andrew >=20 Thanks, Mike