Should "dir" override the full path encoded in debug info?

Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

Hello all,

One of my coworkers just attracted my attention to the semantics of
the "dir" command.

Our compiler fixes are tested through a mechanism where we submit
a patch to our testing engine. It then applies the patch to the sources
of the night before, rebuilds the compiler, reruns our testsuite, and
then send the differences. In order to facilitate the investigation
of regressions, we also make a copy of the resulting compiler in
a separate location. Once all this is completed, the nightly compiler
is restored in order to get ready for the next testing job.

My coworker tried to run the debugger using that copy of the executable
and used "dir" commands to point to his copy of the sources.
Unfortunately, that didn't work as the debugger insisted on using
the original location for getting the source files.

The issue comes from the fact that the compiler sources seem to be
compiled using full path names, or in a way that causes the AT_name
attribute of the compilation unit to be a full path.

And then, when I look at find_and_open_source(), and how it gets called
through open_source_file() (called by print_source_lines_base()), it
almost seems like it was a deliberate decision to objey the fullpath
if available rather than let the "dir" path override the debugging
info.

    /* Open a source file given a symtab S.  Returns a file descriptor or
       negative number for error.  
       
       This function is a convience function to find_and_open_source. */
    
    int
    open_source_file (struct symtab *s)
    {
      if (!s)
        return -1;
    
      return find_and_open_source (s->objfile, s->filename, s->dirname,
                                   &s->fullname);
    }   

Is that really so, or is this a bug?

Note that in most cases, we compile files using relative file names.
And under these circumstances, the "dir" path overrides the path
provided by the debugging info. This is inconsistent.

Thanks,
-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Daniel Jacobowitz]

On Fri, Jun 23, 2006 at 01:10:19PM -0700, Joel Brobecker wrote:
> Our compiler fixes are tested through a mechanism where we submit
> a patch to our testing engine. It then applies the patch to the sources
> of the night before, rebuilds the compiler, reruns our testsuite, and
> then send the differences. In order to facilitate the investigation
> of regressions, we also make a copy of the resulting compiler in
> a separate location. Once all this is completed, the nightly compiler
> is restored in order to get ready for the next testing job.

It is quite likely that what you really want is not "dir", but this:

  http://sourceware.org/ml/gdb/2006-03/msg00189.html

Hey, Paul...

> My coworker tried to run the debugger using that copy of the executable
> and used "dir" commands to point to his copy of the sources.
> Unfortunately, that didn't work as the debugger insisted on using
> the original location for getting the source files.
> 
> The issue comes from the fact that the compiler sources seem to be
> compiled using full path names, or in a way that causes the AT_name
> attribute of the compilation unit to be a full path.
> 
> And then, when I look at find_and_open_source(), and how it gets called
> through open_source_file() (called by print_source_lines_base()), it
> almost seems like it was a deliberate decision to objey the fullpath
> if available rather than let the "dir" path override the debugging
> info.

This might be a bug, or it might not.  But generally "dir" is used only
for files which could not be found; first try the normal location, then
try the search path.  This is the same thing we do for shared libraries
(which implies that the new command would be sort-of an analog for set
solib-absolute-prefix).  Changing anything here is tricky, because of
the case of multiple directories with files with the same name...


-- 
Daniel Jacobowitz
CodeSourcery

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> It is quite likely that what you really want is not "dir", but this:
> 
>   http://sourceware.org/ml/gdb/2006-03/msg00189.html
> 
> Hey, Paul...

Indeed, that would solve the proble entirely. I wonder how this should
be implemented... Should the command store the rewriting rule, and have
find_and_open_source() use it when trying to locate source files?

> This might be a bug, or it might not.  But generally "dir" is used only
> for files which could not be found; first try the normal location, then
> try the search path.  This is the same thing we do for shared libraries
> (which implies that the new command would be sort-of an analog for set
> solib-absolute-prefix).  Changing anything here is tricky, because of
> the case of multiple directories with files with the same name...

Indeed, same file name used more than once in a project is an issue.
Perhaps the argument I was making saying that it "works" in most cases
is backwards, and it actually "works" in my coworker's case while it's
broken for most cases. I'm not sure I would thrilled at the prospect
of fixing this, knowing how delicate this can be.

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Paul Koning]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

 >> It is quite likely that what you really want is not "dir", but
 >> this:
 >> 
 >> http://sourceware.org/ml/gdb/2006-03/msg00189.html
 >> 
 >> Hey, Paul...

 Joel> Indeed, that would solve the proble entirely. I wonder how this
 Joel> should be implemented... Should the command store the rewriting
 Joel> rule, and have find_and_open_source() use it when trying to
 Joel> locate source files?

I forgot where I put it.  What I did is a simple rewriting rule -- a
command with two string arguments, where one is the string to find in
the filenames and the other the replacement string.  A fancier
solution would have multiple substitution pairs, and/or regular
expressions.  For our purposes, one pair with simple strings was
sufficient. 

Once I get out from my current time crunch I'll see about digging up
the change and submitting it as a proposed patch.

    paul

Re: Should "dir" override the full path encoded in debug info?

[Eli Zaretskii]

> Date: Fri, 23 Jun 2006 13:10:19 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> My coworker tried to run the debugger using that copy of the executable
> and used "dir" commands to point to his copy of the sources.
> Unfortunately, that didn't work as the debugger insisted on using
> the original location for getting the source files.

As Daniel points out, this is a complicated issue; the relevant code
was changed several times during the last year to cater to several
popular practices wrt source location.  I think, to judge whether this
is a bug or a feature, we need to see more information, like the
original location of the sources during compilation, what file names
are recorded in the debug info, the "dir" command that was issued at
debug time, and the unwanted behavior and/or the error message(s), if
any, from GDB.

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> As Daniel points out, this is a complicated issue; the relevant code
> was changed several times during the last year to cater to several
> popular practices wrt source location.  I think, to judge whether this
> is a bug or a feature, we need to see more information, like the
> original location of the sources during compilation, what file names
> are recorded in the debug info, the "dir" command that was issued at
> debug time, and the unwanted behavior and/or the error message(s), if
> any, from GDB.

OK, here goes an example using C. Consider the following source file
called foo.c, located in <path>/src.

        #include <stdio.h>
        
        int
        main (void)
        {
          printf ("Hello world.\n");
        }

Cd to <path>/src, and then compile it as follow:

        % gcc -c -g `pwd`/foo.c
        % gcc -o foo foo.o

Then cd one level up to <path> and do the following:

        % cp -R src dup

Now, let's simulate the action of our test engine that undoes the
changes that we just tested. For that, I simply edited the original
file in src/, and change the string.

Next step, we debug the binary we copied. Because we know the relevant
sources are in dup, and not in the original location where they were
located when we did the built, the user used the "dir" command to
point GDB to the new location:

        (gdb) dir dup
        Source directories searched: /<path>/dup:$cdir:$cwd

But then, trying to print the contents of foo.c reveals that we display
the file from the original location. So the "dir" command was not taken
into account:

        (gdb) list foo.c:1
        warning: Source file is more recent than executable.
        1       #include <stdio.h>
        2
        3       int
        4       main (void)
        5       {
        6         printf ("Hello modified.\n");
        7       }

It seems from Daniel's answer that this is by design. The document
is not that clear about that, which explained why I asked before
going in and "fixing" it.

The debugging information generated by foo.c is as follow:

   <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
       DW_AT_stmt_list   : 0
       DW_AT_high_pc     : 0x21 33
       DW_AT_low_pc      : 0 0
       DW_AT_producer    : GNU C 3.4.6 for GNAT Pro 5.05w (20060507)
       DW_AT_language    : 1      (ANSI C)
       DW_AT_name        : /t.a/brobecke/moved/ex/src/foo.c

As you can see, the DW_AT_name attribute contains a full path name,
and the DW_AT_comp_dir attribute is ommitted. Normally, what we see
is a relative path name in AT_name, and a comp_dir attribute that
provides the path for that file. For instance:

   <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
       DW_AT_stmt_list   : 0
       DW_AT_high_pc     : 0x21 33
       DW_AT_low_pc      : 0 0
       DW_AT_producer    : GNU C 3.4.6 for GNAT Pro 5.05w (20060507)
       DW_AT_language    : 1      (ANSI C)
       DW_AT_name        : foo.c
       DW_AT_comp_dir    : /t.a/brobecke/moved/ex/src

The above debugging data is obtained if I compile the file with
the same command, but ommitting the `pwd` part. It's interesting
to notice that in this case, the scenario above leads to a different
behavior which actually matches what my coworker expected.

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Eli Zaretskii]

> Date: Fri, 23 Jun 2006 23:59:20 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sources.redhat.com
> 
> Next step, we debug the binary we copied. Because we know the relevant
> sources are in dup, and not in the original location where they were
> located when we did the built, the user used the "dir" command to
> point GDB to the new location:
> 
>         (gdb) dir dup
>         Source directories searched: /<path>/dup:$cdir:$cwd
> 
> But then, trying to print the contents of foo.c reveals that we display
> the file from the original location. So the "dir" command was not taken
> into account:
> 
>         (gdb) list foo.c:1
>         warning: Source file is more recent than executable.

What happens if you remove or rename the file foo.c in the original
location?

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> >         (gdb) list foo.c:1
> >         warning: Source file is more recent than executable.
> 
> What happens if you remove or rename the file foo.c in the original
> location?

GDB finds the file in dup/. But in our case, we cannot touch the file
in the original location, since the testsuite engine needs it for the
next testing batch. Building in a different location is not an option
either because we want to only recompile the files we touched (and
their dependencies). So basically, at this time, it appears that we're
stuck.

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Eli Zaretskii]

> Date: Sat, 24 Jun 2006 00:10:58 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sources.redhat.com
> 
> > >         (gdb) list foo.c:1
> > >         warning: Source file is more recent than executable.
> > 
> > What happens if you remove or rename the file foo.c in the original
> > location?
> 
> GDB finds the file in dup/.

Then I think this is by design: GDB gives preference to existing files
in the default places.

> So basically, at this time, it appears that we're stuck.

You could try duping GDB into not finding the original file with some
symlink trick.

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> Then I think this is by design: GDB gives preference to existing files
> in the default places.

That's fine. But then how do you explain that when you compile
differently GDB now finds the files in the new location, despite
the fact that the files in the original location are still present
(and the debugging info contains the path to the original files)?
Isn't that inconsistent?

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Daniel Jacobowitz]

On Sat, Jun 24, 2006 at 12:51:43AM -0700, Joel Brobecker wrote:
> > Then I think this is by design: GDB gives preference to existing files
> > in the default places.
> 
> That's fine. But then how do you explain that when you compile
> differently GDB now finds the files in the new location, despite
> the fact that the files in the original location are still present
> (and the debugging info contains the path to the original files)?
> Isn't that inconsistent?

I think that's a bug, but the fix for the bug won't make you any
happier - if told to fix it, I'd probably make the compilation
directory be searched first.  But don't quote me on that; I haven't
looked at this code in a while (I have another bug to fix in it but it
takes me so long to re-internalize how it works that I haven't done it
yet).

-- 
Daniel Jacobowitz
CodeSourcery

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> I think that's a bug, but the fix for the bug won't make you any
> happier - if told to fix it, I'd probably make the compilation
> directory be searched first.  But don't quote me on that; I haven't
> looked at this code in a while (I have another bug to fix in it but it
> takes me so long to re-internalize how it works that I haven't done it
> yet).

That's what I thought too. I don't think it's a big deal because
our setup is probably pretty rare. I'll see about the new rewrite
command. Any suggestion on the name of that new command and its
syntax. Something like this?

        (gdb) rewrite-source-path old-pattern new-pattern

Or rewrite-source-dir. It's a bit on the longer side, but can't find
any better name. Help!

Thanks,
-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Paul Koning]

>>>>> "Joel" == Joel Brobecker <brobecker@adacore.com> writes:

 >> I think that's a bug, but the fix for the bug won't make you any
 >> happier - if told to fix it, I'd probably make the compilation
 >> directory be searched first.  But don't quote me on that; I
 >> haven't looked at this code in a while (I have another bug to fix
 >> in it but it takes me so long to re-internalize how it works that
 >> I haven't done it yet).

 Joel> That's what I thought too. I don't think it's a big deal
 Joel> because our setup is probably pretty rare. I'll see about the
 Joel> new rewrite command. Any suggestion on the name of that new
 Joel> command and its syntax. Something like this?

 Joel> (gdb) rewrite-source-path old-pattern new-pattern

 Joel> Or rewrite-source-dir. It's a bit on the longer side, but can't
 Joel> find any better name. Help!

I called it "source-substitution" but "rewrite-source-path" is
clearer.  I wouldn't make it "rewrite-source-dir". At least in my
case, it's a rewrite of the entire name, so (in theory at elast) it
could rewrite the filename.  In our case that hasn't been needed but
why disallow it?

    paul

Re: Should "dir" override the full path encoded in debug info?

[Eli Zaretskii]

> Date: Sat, 24 Jun 2006 21:07:15 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Any suggestion on the name of that new command and its
> syntax. Something like this?
> 
>         (gdb) rewrite-source-path old-pattern new-pattern
> 
> Or rewrite-source-dir.

I think there's no need to mention `source', since `dir' doesn't,
either.  So how about `subst-dir' or `alt-dir'?

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> I think there's no need to mention `source', since `dir' doesn't,
> either.  So how about `subst-dir' or `alt-dir'?

I'm ok with alt-dir. Any objection?

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Daniel Jacobowitz]

On Sun, Jun 25, 2006 at 06:53:18PM -0700, Joel Brobecker wrote:
> > I think there's no need to mention `source', since `dir' doesn't,
> > either.  So how about `subst-dir' or `alt-dir'?
> 
> I'm ok with alt-dir. Any objection?

I think it's been condensed a little too far; I'd think it was an
alternate to "dir", which isn't quite the case.  Would substitute-dir
be too wordy?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Should "dir" override the full path encoded in debug info?

[Bob Rossi]

On Sun, Jun 25, 2006 at 09:56:36PM -0400, Daniel Jacobowitz wrote:
> On Sun, Jun 25, 2006 at 06:53:18PM -0700, Joel Brobecker wrote:
> > > I think there's no need to mention `source', since `dir' doesn't,
> > > either.  So how about `subst-dir' or `alt-dir'?
> > 
> > I'm ok with alt-dir. Any objection?
> 
> I think it's been condensed a little too far; I'd think it was an
> alternate to "dir", which isn't quite the case.  Would substitute-dir
> be too wordy?

Please correct me if I'm wrong, but wouldn't something like 
substitute-path be more correct. I mean, this doesn't relate to a dir or
a filename does it? I may not completly understand what the new
functions input/output is though.

Bob Rossi

Re: Should "dir" override the full path encoded in debug info?

[Daniel Jacobowitz]

On Sun, Jun 25, 2006 at 10:03:34PM -0400, Bob Rossi wrote:
> On Sun, Jun 25, 2006 at 09:56:36PM -0400, Daniel Jacobowitz wrote:
> > On Sun, Jun 25, 2006 at 06:53:18PM -0700, Joel Brobecker wrote:
> > > > I think there's no need to mention `source', since `dir' doesn't,
> > > > either.  So how about `subst-dir' or `alt-dir'?
> > > 
> > > I'm ok with alt-dir. Any objection?
> > 
> > I think it's been condensed a little too far; I'd think it was an
> > alternate to "dir", which isn't quite the case.  Would substitute-dir
> > be too wordy?
> 
> Please correct me if I'm wrong, but wouldn't something like 
> substitute-path be more correct. I mean, this doesn't relate to a dir or
> a filename does it? I may not completly understand what the new
> functions input/output is though.

Works for me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Should "dir" override the full path encoded in debug info?

[Daniel Jacobowitz]

On Sun, Jun 25, 2006 at 10:03:34PM -0400, Bob Rossi wrote:
> On Sun, Jun 25, 2006 at 09:56:36PM -0400, Daniel Jacobowitz wrote:
> > On Sun, Jun 25, 2006 at 06:53:18PM -0700, Joel Brobecker wrote:
> > > > I think there's no need to mention `source', since `dir' doesn't,
> > > > either.  So how about `subst-dir' or `alt-dir'?
> > > 
> > > I'm ok with alt-dir. Any objection?
> > 
> > I think it's been condensed a little too far; I'd think it was an
> > alternate to "dir", which isn't quite the case.  Would substitute-dir
> > be too wordy?
> 
> Please correct me if I'm wrong, but wouldn't something like 
> substitute-path be more correct. I mean, this doesn't relate to a dir or
> a filename does it? I may not completly understand what the new
> functions input/output is though.

Works for me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> > Please correct me if I'm wrong, but wouldn't something like 
> > substitute-path be more correct. I mean, this doesn't relate to a dir or
> > a filename does it? I may not completly understand what the new
> > functions input/output is though.
> 
> Works for me.

substitute-path works for me too. (and I verified, no collision with
other commands).

Right now, the interface I have in mind is the following.

        (gdb) substitute-path from to

                Sets the substitution rule using "from" and "to".

        (gdb) substitute-path

                Delete the substitution rule

It just occured to me: Should add a way to show the current substitution
pattern? The "show" command prefix doesn't lend itself too well because
we have two arguments. Or perhaps is it ok to define our own processing
for the "show substitute-path" command:

        (gdb) show substitute-path
        Source paths are modified by substituting "from" with "to".

Thanks,
-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> > Please correct me if I'm wrong, but wouldn't something like 
> > substitute-path be more correct. I mean, this doesn't relate to a dir or
> > a filename does it? I may not completly understand what the new
> > functions input/output is though.
> 
> Works for me.

substitute-path works for me too. (and I verified, no collision with
other commands).

Right now, the interface I have in mind is the following.

        (gdb) substitute-path from to

                Sets the substitution rule using "from" and "to".

        (gdb) substitute-path

                Delete the substitution rule

It just occured to me: Should add a way to show the current substitution
pattern? The "show" command prefix doesn't lend itself too well because
we have two arguments. Or perhaps is it ok to define our own processing
for the "show substitute-path" command:

        (gdb) show substitute-path
        Source paths are modified by substituting "from" with "to".

Thanks,
-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

>> > Please correct me if I'm wrong, but wouldn't something like 
>> > substitute-path be more correct. I mean, this doesn't relate to a dir or
>> > a filename does it? I may not completly understand what the new
>> > functions input/output is though.
>> 
>> Works for me.
>
> substitute-path works for me too. (and I verified, no collision with
> other commands).
>
> Right now, the interface I have in mind is the following.
>
>         (gdb) substitute-path from to
>
>                 Sets the substitution rule using "from" and "to".

How about adding subcommands `add' and `remove' and having more than one
substitution rule?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Should "dir" override the full path encoded in debug info?

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

>> > Please correct me if I'm wrong, but wouldn't something like 
>> > substitute-path be more correct. I mean, this doesn't relate to a dir or
>> > a filename does it? I may not completly understand what the new
>> > functions input/output is though.
>> 
>> Works for me.
>
> substitute-path works for me too. (and I verified, no collision with
> other commands).
>
> Right now, the interface I have in mind is the following.
>
>         (gdb) substitute-path from to
>
>                 Sets the substitution rule using "from" and "to".

How about adding subcommands `add' and `remove' and having more than one
substitution rule?

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> How about adding subcommands `add' and `remove' and having more than one
> substitution rule?

I personally think that would be overkill... Others?

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> How about adding subcommands `add' and `remove' and having more than one
> substitution rule?

I personally think that would be overkill... Others?

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Bob Rossi]

On Mon, Jun 26, 2006 at 07:50:37AM -0700, Joel Brobecker wrote:
> > How about adding subcommands `add' and `remove' and having more than one
> > substitution rule?
> 
> I personally think that would be overkill... Others?

Well, it seem to me that eventually users will need to subsitute 
multiple paths. So, it makes sense to support it right away. I don't
know if add/remove is the best way. It would be a good idea to also
consider a key/value colon separated list. Where if they want to use :,
they will have to escape it (\).

substitute-path /home/foo=/home/bar:/home/foo\:1=/home/foo\:2

Just some ideas.

Bob Rossi

Re: Should "dir" override the full path encoded in debug info?

[Bob Rossi]

On Mon, Jun 26, 2006 at 07:50:37AM -0700, Joel Brobecker wrote:
> > How about adding subcommands `add' and `remove' and having more than one
> > substitution rule?
> 
> I personally think that would be overkill... Others?

Well, it seem to me that eventually users will need to subsitute 
multiple paths. So, it makes sense to support it right away. I don't
know if add/remove is the best way. It would be a good idea to also
consider a key/value colon separated list. Where if they want to use :,
they will have to escape it (\).

substitute-path /home/foo=/home/bar:/home/foo\:1=/home/foo\:2

Just some ideas.

Bob Rossi

Re: Should "dir" override the full path encoded in debug info?

[Andrew STUBBS]

Bob Rossi wrote:
> On Mon, Jun 26, 2006 at 07:50:37AM -0700, Joel Brobecker wrote:
>>> How about adding subcommands `add' and `remove' and having more than one
>>> substitution rule?
>> I personally think that would be overkill... Others?
> 
> Well, it seem to me that eventually users will need to subsitute 
> multiple paths. So, it makes sense to support it right away. I don't
> know if add/remove is the best way. It would be a good idea to also
> consider a key/value colon separated list. Where if they want to use :,
> they will have to escape it (\).
> 
> substitute-path /home/foo=/home/bar:/home/foo\:1=/home/foo\:2

Let's not forget Windows here. The colon might be a problem.

I don't think the dir command currently uses (semi-)colon for input, 
only output, so scripts remain compatible.

Andrew

Re: Should "dir" override the full path encoded in debug info?

[Andrew STUBBS]

Bob Rossi wrote:
> On Mon, Jun 26, 2006 at 07:50:37AM -0700, Joel Brobecker wrote:
>>> How about adding subcommands `add' and `remove' and having more than one
>>> substitution rule?
>> I personally think that would be overkill... Others?
> 
> Well, it seem to me that eventually users will need to subsitute 
> multiple paths. So, it makes sense to support it right away. I don't
> know if add/remove is the best way. It would be a good idea to also
> consider a key/value colon separated list. Where if they want to use :,
> they will have to escape it (\).
> 
> substitute-path /home/foo=/home/bar:/home/foo\:1=/home/foo\:2

Let's not forget Windows here. The colon might be a problem.

I don't think the dir command currently uses (semi-)colon for input, 
only output, so scripts remain compatible.

Andrew

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> > How about adding subcommands `add' and `remove' and having more than one
> > substitution rule?
> 
> I personally think that would be overkill... Others?

However, the idea of having

        (gdb) substitute-path add from to
        (gdb) substitute-path remove
        (gdb) substitute-path

Is interesting. The third case would print the current substitution rule.

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Joel Brobecker]

> > How about adding subcommands `add' and `remove' and having more than one
> > substitution rule?
> 
> I personally think that would be overkill... Others?

However, the idea of having

        (gdb) substitute-path add from to
        (gdb) substitute-path remove
        (gdb) substitute-path

Is interesting. The third case would print the current substitution rule.

-- 
Joel

Re: Should "dir" override the full path encoded in debug info?

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

> However, the idea of having
>
>         (gdb) substitute-path add from to
>         (gdb) substitute-path remove
>         (gdb) substitute-path
>
> Is interesting. The third case would print the current substitution rule.

The latter functionality should be a subcommand of show.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Should "dir" override the full path encoded in debug info?

[Andreas Schwab]

Joel Brobecker <brobecker@adacore.com> writes:

> However, the idea of having
>
>         (gdb) substitute-path add from to
>         (gdb) substitute-path remove
>         (gdb) substitute-path
>
> Is interesting. The third case would print the current substitution rule.

The latter functionality should be a subcommand of show.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Should "dir" override the full path encoded in debug info?

[Eli Zaretskii]

> Date: Sun, 25 Jun 2006 22:03:34 -0400
> From: Bob Rossi <bob_rossi@cox.net>
> 
> Please correct me if I'm wrong, but wouldn't something like 
> substitute-path be more correct. I mean, this doesn't relate to a dir or
> a filename does it?

I suggested *-dir because it modifies what `dir' does.  It's true that
it relates to a path, but so does `dir'.

Re: Should "dir" override the full path encoded in debug info?

[Eli Zaretskii]

> Date: Sun, 25 Jun 2006 21:56:36 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Eli Zaretskii <eliz@gnu.org>, gdb@sources.redhat.com
> 
> > I'm ok with alt-dir. Any objection?
> 
> I think it's been condensed a little too far; I'd think it was an
> alternate to "dir", which isn't quite the case.

But it's close.

> Would substitute-dir be too wordy?

Fine with me, but let's have subst-dir (or just subst) as an alias.

Re: Should "dir" override the full path encoded in debug info?

[Eli Zaretskii]

> Date: Sat, 24 Jun 2006 00:51:43 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb@sources.redhat.com
> 
> But then how do you explain that when you compile
> differently GDB now finds the files in the new location, despite
> the fact that the files in the original location are still present
> (and the debugging info contains the path to the original files)?

You lost me here: I cannot figure out what does ``compile
differently'' mean, exactly.