From: Simon Marchi <simark@simark.ca>
To: John Baldwin <jhb@FreeBSD.org>, gdb-patches@sourceware.org
Subject: Re: [PATCH 2/2] Trim trailing directory separators from new sysroots.
Date: Sat, 26 Jan 2019 19:10:00 -0000 [thread overview]
Message-ID: <1577437a-a984-4401-216f-dca1e0b18872@simark.ca> (raw)
In-Reply-To: <2c219947da76ada8ee0596dc61a4abef3ebdc256.1548205042.git.jhb@FreeBSD.org>
On 2019-01-22 8:03 p.m., John Baldwin wrote:
> The separate debugfile logic assumes that the sysroot does not include
> a trailing separator (all of the sysroot logic in
> find_separate_debug_file requires the next character after the sysroot
> in a object file path to be a directory separator). However, normal
> filename completion will result in setting a sysroot with a trailing
> directory separator. If the directory portion of a new sysroot ends
> with a directory separator and is not specifying the root directory,
> trim the trailing separator. This permits the sysroot logic to work
> the same if a sysroot of "/myroot/" is specified instead of "/myroot".
>
> Note that the sysroot displayed by 'show sysroot' will reflect the
> trimmed sysroot.
I am not sure about this, it seems fragile to do this one off thing. The
point where the path is stripped is quite far from the point where it has
an impact, so it's really not obvious why we do it (though this could be
fixed by saying why we do it in the comment).
I think it would be a step in a better direction to have an "is_child_path"
function that returns whether a path is a child of another one. It would
be responsible for handling the case of the parent potentially having a
trailing directory separator. The implementation of such function might
get hairy, but the advantage is that it should be pretty easy to unit
test.
Finally, I think it would make this code more obvious:
if (canon_dir != NULL
&& filename_ncmp (canon_dir, gdb_sysroot,
strlen (gdb_sysroot)) == 0
&& IS_DIR_SEPARATOR (canon_dir[strlen (gdb_sysroot)]))
vs
if (canon_dir != NULL && is_child_patn (gdb_sysroot, canon_dir))
Simon
next prev parent reply other threads:[~2019-01-26 19:10 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-01-23 1:04 [PATCH 0/2] Some fixes for debug files and sysroots John Baldwin
2019-01-23 1:04 ` [PATCH 1/2] Look for separate debug files in debug directories under a sysroot John Baldwin
2019-01-26 5:17 ` Simon Marchi
2019-01-26 17:12 ` Simon Marchi
2019-01-28 18:53 ` John Baldwin
2019-02-22 20:51 ` Simon Marchi
2019-01-23 1:04 ` [PATCH 2/2] Trim trailing directory separators from new sysroots John Baldwin
2019-01-26 19:10 ` Simon Marchi [this message]
2019-01-28 20:41 ` John Baldwin
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=1577437a-a984-4401-216f-dca1e0b18872@simark.ca \
--to=simark@simark.ca \
--cc=gdb-patches@sourceware.org \
--cc=jhb@FreeBSD.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