From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47106 invoked by alias); 13 Sep 2019 22:11:04 -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 47095 invoked by uid 89); 13 Sep 2019 22:11:03 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-25.2 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.1 spammy=HTo:U*eliz, HX-Spam-Relays-External:sk:us-smtp, HX-HELO:sk:us-smtp, H*RU:sk:us-smtp X-HELO: us-smtp-1.mimecast.com Received: from us-smtp-delivery-1.mimecast.com (HELO us-smtp-1.mimecast.com) (205.139.110.120) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Sep 2019 22:11:01 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mathworks.com; s=mimecast20180117; t=1568412659; 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=DW0VdlRmltbg+gEYj5LCGmhxkDI3wihwVYXsQUR/+3k=; b=VjbgEhb49KYw7U82h8CX/pB3O3eFPQTtlS6kLwq403Fw/mfminA7X3UtUdGxuaadhTpgON cFBQlLsxQ3qLomvkqL/LZ2jh8Wn+r/+rfM1n7TBQcF0yq1+HATiNutAL1E8lWc/rDl+iy6 J4rcH+RwbFPQkYAYaYDRF6DUvRXq1vY= Received: from NAM03-BY2-obe.outbound.protection.outlook.com (mail-by2nam03lp2054.outbound.protection.outlook.com [104.47.42.54]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-14-8zEG5iVfNyWyEOF08HVkkA-1; Fri, 13 Sep 2019 18:10:57 -0400 Received: from DM6PR05MB4156.namprd05.prod.outlook.com (20.176.72.29) by DM6PR05MB5497.namprd05.prod.outlook.com (20.176.122.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.11; Fri, 13 Sep 2019 22:10:54 +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:10:54 +0000 From: Mike Gulick To: Eli Zaretskii , Andrew Burgess CC: Mike Gulick , "gdb-patches@sourceware.org" Subject: Re: [RFC] Apply compilation dir to source_path lookup Date: Fri, 13 Sep 2019 22:11:00 -0000 Message-ID: <6e920f8f-574a-8ba2-03c1-37ee19e61906@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> In-Reply-To: <835zlw1z45.fsf@gnu.org> x-ms-exchange-transport-forked: True x-ms-oob-tlc-oobclassifiers: OLM:9508; x-ms-exchange-senderadcheck: 1 Content-ID: <3FA38C016127214393B96FBB72931898@namprd05.prod.outlook.com> MIME-Version: 1.0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LqJ8Zj313kdW76sCkchuWimRI+Fcme3o3fog5n3Kku+NCiqJG6XnN5RFORkKZB0vhBl9si0EZ7z01cxaqwO0xA== X-Mimecast-Spam-Score: 0 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable X-SW-Source: 2019-09/txt/msg00244.txt.bz2 On 9/13/19 2:36 AM, Eli Zaretskii wrote: >> Date: Thu, 12 Sep 2019 21:38:51 -0400 >> From: Andrew Burgess >> Cc: "gdb-patches@sourceware.org" , >> Eli Zaretskii >> >> diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo >> index 79824a0226a..b6b87b28b9f 100644 >> --- a/gdb/doc/gdb.texinfo >> +++ b/gdb/doc/gdb.texinfo >> @@ -8968,9 +8968,23 @@ >> Plain file names, relative file names with leading directories, file >> names containing dots, etc.@: are all treated as described above; for >> instance, if the source path is @file{/mnt/cross}, and the source file >> -is recorded as @file{../lib/foo.c}, @value{GDBN} would first try >> -@file{../lib/foo.c}, then @file{/mnt/cross/../lib/foo.c}, and after >> -that---@file{/mnt/cross/foo.c}. >> +is recorded as @file{../lib/foo.c} and no compilation directory is >> +recorded, @value{GDBN} would first try @file{../lib/foo.c}, then >> +@file{/mnt/cross/../lib/foo.c}, and after that >> +@file{/mnt/cross/foo.c}. >> + >> +When there is both a filename and a compilation directory in the debug >> +information, and if @value{GDBN} hasn't found the source file using >> +the above approach, then @value{GDBN} will append the filename to the >> +compilation directory and retry using the above steps; for instance, >> +if the source path is @file{/mnt/cross}, and the source file is >> +recorded as @file{../lib/foo.c} and the compilation directory is >> +recorded as @file{/usr/src/foo-1.0/build}, @value{GDBN} would first >> +try @file{../lib/foo.c}, then @file{/mnt/cross/../lib/foo.c}, then >> +@file{/mnt/cross/foo.c}, using the approach outlined above. If the >> +source file still hasn't been found then @value{GDBN} will next check >> +@file{/usr/src/foo-1.0/build/../lib/foo.c}, then >> +@file{/mnt/cross/usr/src/foo-1.0/build/../lib/foo.c}. >=20 > This text is unnecessarily long and complicated. How about this > shortened version -- does it correctly convey the intent? >=20 > Plain file names, relative file names with leading directories, file > names containing dots, etc.@: are all treated as described above; for > instance, if the source path is @file{/mnt/cross}, and the source file > is recorded as @file{../lib/foo.c}, @value{GDBN} would first try > @file{../lib/foo.c}, then @file{/mnt/cross/../lib/foo.c}, and after > that---@file{/mnt/cross/foo.c}. > If the above search fails to find the source file @file{foo.c}, and > the compilation directory is recorded in the debug information, > @value{GDBN} will repeat the search using the compilation directory > as if it were in the source path. This doesn't quite capture the change. The original documentation wasn't quite right to start with either. If I'm understanding find_and_open_source correctly, GDB would actually search for /mnt/cross/../lib/foo.c before searching for ../lib/foo.c. Only if the source file is an absolute path does openp first try the filename on its own (see OPF_TRY_CWD_FIRST). For the purposes of this example, let's call the source filename from DW_AT_name SOURCE_FILE, the compilation directory from DW_AT_comp_dir COMP_DIR, and let's say source_path contained '/a:/b:$cdir:$cwd'. As we know, GDB enforces that '$cdir' (the compilation directory) and '$cwd' (the current working directory) are the last two entries on the source path. Prior to this change, I believe GDB would search in the following order: # First openp call searches: SOURCE_FILE (only if SOURCE_FILE is absolute) /a/SOURCE_FILE /b/SOURCE_FILE $cdir/SOURCE_FILE $cwd/SOURCE_FILE # Second openp call searches: /a/basename(SOURCE_FILE) /b/basename(SOURCE_FILE) $cdir/basename(SOURCE_FILE) $cwd/basename(SOURCE_FILE) After this change, GDB will search in the following order # First openp call searches: SOURCE_FILE (only if SOURCE_FILE is absolute) /a/SOURCE_FILE /b/SOURCE_FILE $cdir/SOURCE_FILE $cwd/SOURCE_FILE # Second (new) openp call searches: COMP_DIR/SOURCE_FILE (only if COMP_DIR is absolute) /a/COMP_DIR/SOURCE_FILE /b/COMP_DIR/SOURCE_FILE $cdir/COMP_DIR/SOURCE_FILE $cwd/COMP_DIR/SOURCE_FILE # Third openp call searches: /a/basename(SOURCE_FILE) /b/basename(SOURCE_FILE) $cdir/basename(SOURCE_FILE) $cwd/basename(SOURCE_FILE) In all cases, if there is no recorded compilation directory, any entries referring to $cdir or COMP_DIR will be skipped. Clearly the search for $cdir/COMP_DIR/SOURCE_FILE is unnecessary. I had thought it seemed like more work to construct a new source_path with the compilation directory removed than it is to leave it there under the assumption that it won't exist. Actually, if we call result =3D openp (source_path, flags, cdir_filename.c_str (), OPEN_MODE, fullname); rather than result =3D openp (path, flags, cdir_filename.c_str (), OPEN_MODE, fullname); for this particular search, source_path will contain '$cdir' explicitly, rather than the expanded form, and will be ignored by the continue on line 820. That's probably a worthwhile modification. The two examples in the documentation (with the absolute path and the relative path) fall a little short. They don't capture the difference that the relative path is *not* attempted before the search path. They also don't describe how the compilation directory is taken into account. Perhaps it would be better to just lay out the search order as a list like I have above? >=20 >> @value{GDBN} will also append the compilation >> +directory to the filename and check this against all other entries in >> +the source path. >=20 > 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? >=20 > Thanks. >=20 Thanks, Mike