From: Daniel Jacobowitz <drow@false.org>
To: Joel Brobecker <brobecker@adacore.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA] set/unset/show substitute-path commands (take 2)
Date: Mon, 24 Jul 2006 20:25:00 -0000 [thread overview]
Message-ID: <20060724202545.GD15759@nevyn.them.org> (raw)
In-Reply-To: <20060719181516.GO15273@adacore.com>
On Wed, Jul 19, 2006 at 11:15:16AM -0700, Joel Brobecker wrote:
> I adjusted the testcase according to the modifications in the code.
> I also tried to add a test that would verify that the substitution
> correctly takes place, but as expected, I'm having some trouble
> doing that. Here is what I did:
>
> * gdb.base/subst.exp
> * gdb.base/subst.c
> * gdb.base/subst.dir/subst.c
>
> The version of subst.c in subst.dir is a modified version of subst.c.
> I built the subst executable using gdb.base/subst.c, as usual. And then
> tried to add a substitution rule as follow:
>
> (gdb) set substitute-path '${srcdir}/${subdir}' '${srcdir}/${subdir}/subst.dir'
>
> But the problem is that ${srcdir} is not string equal to what compiler
> put in the debugging information. As far as I can tell from the testcase
> output, ${srcdir} is something like ../../gdb/testsuite. I don't see how
> to reliably get the source path in a way that would be identical to what
> the compiler sets.
>
> Perhaps this is telling us that, instead of just FILENAME_CMP, we should
> use something more sophisticated like xfullpath to check for path equality.
> But I'm very reluctant to even suggest that, because performance would
> probably become horrendous on large applications where lots and lots of
> files are used.
Let's not go towards xfullpath for this please. The whole problem is
that we don't want to rely on build-time paths if told not to; we
shouldn't be affected by what's on the disk now.
The best way to handle this is to ask the compiler. Try loading the
binary and running "info source"; it will print out the compilation
directory.
> /* Quick way out if we already know its full name */
> +
> if (*fullname)
> {
> + {
> + /* The user may have requested that source paths be rewritten
> + according to substitution rules he provided. If a substitution
> + rule applies to this path, then apply it. */
> + char *rewritten_fullname = rewrite_source_path (*fullname);
> +
> + if (rewritten_fullname != NULL)
> + {
> + xfree (*fullname);
> + *fullname = rewritten_fullname;
> + }
> + }
> +
> result = open (*fullname, OPEN_MODE);
> if (result >= 0)
> return result;
You don't need the extra { } here.
> +/* If the last character of PATH is a directory separator, then strip it. */
> +
> +static void
> +strip_trailing_directory_separator (char *path)
> +{
> + const int last = strlen (path) - 1;
> +
> + if (last < 0)
> + return; /* No stripping is needed if PATH is the empty string. */
> +
> + if (IS_DIR_SEPARATOR (path[last]))
> + path[last] = '\0';
> +}
Is this going to get you in trouble if PATH is "/" ? I can imagine
that happening.
> +/* A convenience function to push ARGV in the cleanup queue. */
> +
> +static void
> +make_cleanup_argv (char **argv)
> +{
> + make_cleanup ((make_cleanup_ftype *) freeargv, argv);
> +}
Casting function types is a good way to get in trouble. In this case,
there's an answer handy: make_cleanup_freeargv.
Otherwise looks great!
--
Daniel Jacobowitz
CodeSourcery
next prev parent reply other threads:[~2006-07-24 20:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-07-15 5:49 Joel Brobecker
2006-07-17 9:19 ` Andrew STUBBS
2006-07-17 9:29 ` Andrew STUBBS
2006-07-17 17:09 ` Joel Brobecker
2006-07-17 17:32 ` Daniel Jacobowitz
2006-07-17 17:46 ` Andrew STUBBS
2006-07-19 18:15 ` Joel Brobecker
2006-07-24 20:25 ` Daniel Jacobowitz [this message]
2006-07-25 16:28 ` Joel Brobecker
2006-07-25 16:38 ` Daniel Jacobowitz
2006-08-08 22:19 ` Joel Brobecker
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=20060724202545.GD15759@nevyn.them.org \
--to=drow@false.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sources.redhat.com \
/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