From: LRN <lrn1986@gmail.com>
To: gdb-patches@sourceware.org
Subject: [PATCH] Apply substitute-path to relative filenames as well
Date: Thu, 28 Feb 2019 12:52:00 -0000 [thread overview]
Message-ID: <5a785bba-7432-f6e0-1089-5d2bdd3450a3@gmail.com> (raw)
[-- Attachment #1.1.1: Type: text/plain, Size: 2417 bytes --]
The patch is attached.
The change itself is similar to
https://www.sourceware.org/ml/gdb-patches/2017-02/msg00693.html , but the code
is slightly cleaner (at the cost of making the patch larger).
Also, as the patch is trivial, so i would expect it to not to require copyright
assignment (i do have one, but David Grayson might not have).
Here's the copy of the commit message:
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/source.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
gdb/ChangeLog:
2019-02-28 Руслан Ижбулатов <lrn1986@gmail.com>
* source.c (find_and_open_source): Apply substitute-path to all
filenames, both absolute and relative
[-- Attachment #1.1.2: 0001-Apply-substitute-path-to-relative-filenames-as-well.patch --]
[-- Type: text/plain, Size: 2876 bytes --]
From 28431cdf98ec6c606373fd02c36c5642c4f196df Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?=D0=A0=D1=83=D1=81=D0=BB=D0=B0=D0=BD=20=D0=98=D0=B6=D0=B1?=
=?UTF-8?q?=D1=83=D0=BB=D0=B0=D1=82=D0=BE=D0=B2?= <lrn1986@gmail.com>
Date: Thu, 28 Feb 2019 10:25:41 +0000
Subject: [PATCH] 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/source.c | 12 ++++--------
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/gdb/source.c b/gdb/source.c
index f99215f..673ebc3 100644
--- a/gdb/source.c
+++ b/gdb/source.c
@@ -1028,15 +1028,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);
- if (rewritten_filename != NULL)
- filename = rewritten_filename.get ();
- }
+ rewritten_filename = rewrite_source_path (filename);
+
+ if (rewritten_filename != NULL)
+ filename = rewritten_filename.get ();
result = openp (path, OPF_SEARCH_IN_PATH | OPF_RETURN_REALPATH, filename,
OPEN_MODE, fullname);
--
2.4.0
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next reply other threads:[~2019-02-28 12:52 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-02-28 12:52 LRN [this message]
2019-03-05 22:24 ` Tom Tromey
2019-03-06 10:06 ` LRN
2019-03-13 12:47 ` LRN
2019-03-20 10:24 ` LRN
2019-03-27 21:36 ` Tom Tromey
2019-03-27 22:59 ` LRN
2019-03-29 20:51 ` Tom Tromey
2019-06-06 18:01 ` Tom Tromey
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=5a785bba-7432-f6e0-1089-5d2bdd3450a3@gmail.com \
--to=lrn1986@gmail.com \
--cc=gdb-patches@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