Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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


  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