From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105967 invoked by alias); 13 Sep 2019 22:41:22 -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 105947 invoked by uid 89); 13 Sep 2019 22:41:21 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-26.1 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy=H*Ad:U*eliz X-HELO: mail-qt1-f193.google.com Received: from mail-qt1-f193.google.com (HELO mail-qt1-f193.google.com) (209.85.160.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 13 Sep 2019 22:41:19 +0000 Received: by mail-qt1-f193.google.com with SMTP id n7so35854063qtb.6 for ; Fri, 13 Sep 2019 15:41:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=GYYsaCe3jT6Woc5rm+uCukZg9mrP5n8uUKJpiVKL2Cw=; b=SqDKjTrgLD4p4McLmvgaao5LpEuNIRD6cChEVR79/qTtLSRW5WEZlL5Wu0sBbvafJu pdIlN7OzyNlvAXhmMgJbJykefe6ufxbvqiq8ckt4haqqaL/usskyGjHRaC/f4EqQ/jzE iHgwOExCdfDosAMsoE4xcWrB0wXroc6MXqY0Lq5yDYQDcamQOciyfpNprRwEGoB945EB 5jhiCbLp3rTUvVjkaBJyYsVy35E0/31I3Cv2F+YW0f4bwNf9PRVmchrtifiyx2VvZJod 4uZNlgfcPeGF0Awr3MMcK3bfys0T+p29ndCRAN+6s2SpWPNUC/gYotRg7Lu6LQsfH58E bzPg== Return-Path: Received: from localhost ([207.253.95.5]) by smtp.gmail.com with ESMTPSA id c126sm12822459qkd.13.2019.09.13.15.41.17 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 13 Sep 2019 15:41:17 -0700 (PDT) Date: Fri, 13 Sep 2019 22:41:00 -0000 From: Andrew Burgess To: Mike Gulick Cc: Eli Zaretskii , "gdb-patches@sourceware.org" Subject: Re: [RFC] Apply compilation dir to source_path lookup Message-ID: <20190913224116.GW6076@embecosm.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> <6e920f8f-574a-8ba2-03c1-37ee19e61906@mathworks.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e920f8f-574a-8ba2-03c1-37ee19e61906@mathworks.com> X-Fortune: For a holy stint, a moth of the cloth gave up his woolens for lint. X-Editor: GNU Emacs [ http://www.gnu.org/software/emacs ] User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes X-SW-Source: 2019-09/txt/msg00246.txt.bz2 * Mike Gulick [2019-09-13 22:10:54 +0000]: > > > 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}. > > > > This text is unnecessarily long and complicated. How about this > > shortened version -- does it correctly convey the intent? > > > > 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. Not exactly, GDB will add '$cdir:$cwd' to the end of the directory list so you can never NOT have these in the search path, but you can bring them earlier in the list: (gdb) show directories Source directories searched: $cdir:$cwd (gdb) set directories $cwd:$cdir:/a/:/b (gdb) show directories Source directories searched: $cwd:$cdir:/a:/b I've both reordered them and brought them to the start of the list. > > 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) I hadn't picked up on the only if absolute subtlety. > /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 = openp (source_path, flags, cdir_filename.c_str (), OPEN_MODE, > fullname); > > rather than > > result = 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. I'm not sure I'm comfortable with that. I did think about this too and figured trying /COMP_DIR/COMP_DIR/SOURCE_FILE was probably harmless, but if you don't like it I think filtering path again to remove $cwd would be required. > > 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? The idea of listing a set of examples might be a better way to go. I'll try to rewrite the docs when I get a chance. Thanks, Andrew > > > > >> @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? > > > > Thanks. > > > > Thanks, > Mike >