public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Tom Tromey <tromey@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] Apply substitute-path to relative filenames as well
Date: Thu, 06 Jun 2019 18:01:00 -0000	[thread overview]
Message-ID: <20190606180113.13654.qmail@sourceware.org> (raw)

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 3700 bytes --]

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=4fa0265edea0940b865678d93749e224547dd36a

commit 4fa0265edea0940b865678d93749e224547dd36a
Author: Руслан Ижбулатов <lrn1986@gmail.com>
Date:   Thu Feb 28 10:25:41 2019 +0000

    Apply substitute-path to relative filenames as well
    
    When source file path is relative to the build directory (which
    is considered a good practice and is enforced in certain buildsystems,
    such as meson), gdb only applies substitute-path to the build directory
    path. Then gdb appends the source file path to the rewritten build
    directory path, and tries to access that.
    
    This fails if either two of the following conditions are true:
    a) The user didn't specify substitute-path for the build directory.
       This is highly likely, since path substitution for build directories
       is not documented anywhere, and since gdb does not tell[0] the user
       the path to the build directory, just the source file path.
    b) The source file path changed.
       This can also easily happen, since a source path that is relative
       to the build directory can include any number of directory names
       that are not part of the program source tree (starting with the
       name of the root directory of the source tree). Gdb will not apply
       substitute-path to that relative path, thus there is no way for
       the user to tell gdb about these changes.
    
    This commit changes the code to apply substitute-path to all filenames,
    both relative and absolute. This way it is possible to do things like:
    
    set substitute-path ../foobar-1.0 /src/my/foobar-1.0
    
    which is completely in line with the user expectations.
    
    This might break unusual cases where build directory path is also
    relative (is that even possible?) and happens to match the path
    to the source directory (i.e. happens to match a substitution rule).
    
    [0]: There's a "maintenance info symtabs" command that does show the names
         of the build directories, but normal users are not required to
         know or use that.
    
    gdb/ChangeLog
    2019-06-06  Руслан Ижбулатов <lrn1986@gmail.com>
    
    	* source.c (find_and_open_source): Also rewrite relative file
    	names.

Diff:
---
 gdb/ChangeLog |  5 +++++
 gdb/source.c  | 13 ++++---------
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 024e171..efe4618 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,8 @@
+2019-06-06  Руслан Ижбулатов <lrn1986@gmail.com>
+
+	* source.c (find_and_open_source): Also rewrite relative file
+	names.
+
 2019-04-26  Amos Bird  <amosbird@gmail.com>
 
 	* annotate.c (annotate_thread_exited): Add "thread-exited"
diff --git a/gdb/source.c b/gdb/source.c
index 9a30209..00052e6 100644
--- a/gdb/source.c
+++ b/gdb/source.c
@@ -1025,16 +1025,11 @@ find_and_open_source (const char *filename,
 	}
     }
 
-  gdb::unique_xmalloc_ptr<char> rewritten_filename;
-  if (IS_ABSOLUTE_PATH (filename))
-    {
-      /* If filename is absolute path, try the source path
-	 substitution on it.  */
-      rewritten_filename = rewrite_source_path (filename);
+  gdb::unique_xmalloc_ptr<char> rewritten_filename
+    = rewrite_source_path (filename);
 
-      if (rewritten_filename != NULL)
-	filename = rewritten_filename.get ();
-    }
+  if (rewritten_filename != NULL)
+    filename = rewritten_filename.get ();
 
   result = openp (path, OPF_SEARCH_IN_PATH | OPF_RETURN_REALPATH, filename,
 		  OPEN_MODE, fullname);


                 reply	other threads:[~2019-06-06 18:01 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190606180113.13654.qmail@sourceware.org \
    --to=tromey@sourceware.org \
    --cc=gdb-cvs@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).