remapping absolute source paths

remapping absolute source paths

[Felix Lee]

Say I have a program that has some absolute path names in
the debugging info, like
    /a/x/foo.c

but /a doesn't exist here.  instead I have the source
in /p.

There's no easy way of making that work right in gdb, is
there?  If I say "dir /p", it's not going to look for
/p/x/foo.c.  If I say "dir /p/x" and for every other subdir
in the tree, then gdb will have problems picking /p/x/foo.c
from /p/y/foo.c

I'm thinking either

  1. there should be a way to tell gdb that "/a" in a
     source path should be remapped to "/p"

  2. gdb should try every sub-path of the sourcefile name,
     so it should try
        /p/a/x/foo.c
        /p/x/foo.c
        etc.

1 is less transparent, but it's easier to control
ambiguities, like if for some reason the executable has both
    /a/x/foo.c
    /b/y/foo.c
which seems unlikely, but I could see it happening when
linking several libraries and packages together.

I'm leaning towards implementing 1.  any thoughts?
--

Re: remapping absolute source paths

[Pierre Muller]

At 08:36 03/10/2002 , Felix Lee a écrit:
>Say I have a program that has some absolute path names in
>the debugging info, like
>     /a/x/foo.c
>
>but /a doesn't exist here.  instead I have the source
>in /p.
>
>There's no easy way of making that work right in gdb, is
>there?  If I say "dir /p", it's not going to look for
>/p/x/foo.c.  If I say "dir /p/x" and for every other subdir
>in the tree, then gdb will have problems picking /p/x/foo.c
>from /p/y/foo.c
>
>I'm thinking either
>
>   1. there should be a way to tell gdb that "/a" in a
>      source path should be remapped to "/p"

Did you try to use
dir /p/..
because it might be that gdb
does try 
/p/../a/x/foo.c
normally this should be 
expanded back into /a/x/foo.c
but we could probably easily get GDB to handle
it the other way around so that it gets translated into
/p/x/foo.c.

This would of course require some documentation
about this new feature, but as dir /p/..
is probably quite useless for now,
it could be adapted for this purpose,
without the need of a new gdb command.



Pierre Muller
Institut Charles Sadron
6,rue Boussingault
F 67083 STRASBOURG CEDEX (France)
mailto:muller@ics.u-strasbg.fr
Phone : (33)-3-88-41-40-07  Fax : (33)-3-88-41-40-99

Re: remapping absolute source paths

[Felix Lee]

Pierre Muller <muller@ics.u-strasbg.fr>:
> Did you try to use
> dir /p/..

it doesn't work, and I don't want it to work.  it doesn't
solve the problem of resolving ambiguous filenames that a
dirname remap would.  besides, it's ugly and wrong.
--

Re: remapping absolute source paths

[Daniel Jacobowitz]

On Wed, Oct 02, 2002 at 11:36:23PM -0700, Felix Lee wrote:
> Say I have a program that has some absolute path names in
> the debugging info, like
>     /a/x/foo.c
> 
> but /a doesn't exist here.  instead I have the source
> in /p.
> 
> There's no easy way of making that work right in gdb, is
> there?  If I say "dir /p", it's not going to look for
> /p/x/foo.c.  If I say "dir /p/x" and for every other subdir
> in the tree, then gdb will have problems picking /p/x/foo.c
> from /p/y/foo.c
> 
> I'm thinking either
> 
>   1. there should be a way to tell gdb that "/a" in a
>      source path should be remapped to "/p"
> 
>   2. gdb should try every sub-path of the sourcefile name,
>      so it should try
>         /p/a/x/foo.c
>         /p/x/foo.c
>         etc.
> 
> 1 is less transparent, but it's easier to control
> ambiguities, like if for some reason the executable has both
>     /a/x/foo.c
>     /b/y/foo.c
> which seems unlikely, but I could see it happening when
> linking several libraries and packages together.
> 
> I'm leaning towards implementing 1.  any thoughts?

Actually, I think that Earl implemented #2 in the message:
  [RFC PATCH] Finding files in source trees
in September.  Earl, mind resending that for more comments?  I think
you satisfied my concerns completely.


-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: remapping absolute source paths

[Earl Chew]

Daniel Jacobowitz wrote:
> On Wed, Oct 02, 2002 at 11:36:23PM -0700, Felix Lee wrote:
> >   2. gdb should try every sub-path of the sourcefile name,
> >      so it should try
> >         /p/a/x/foo.c
> >         /p/x/foo.c
> >         etc.
> >
> > 1 is less transparent, but it's easier to control
> > ambiguities, like if for some reason the executable has both
> >     /a/x/foo.c
> >     /b/y/foo.c
> > which seems unlikely, but I could see it happening when
> > linking several libraries and packages together.
> >
> > I'm leaning towards implementing 1.  any thoughts?
> 
> Actually, I think that Earl implemented #2 in the message:
>   [RFC PATCH] Finding files in source trees
> in September.  Earl, mind resending that for more comments?  I think
> you satisfied my concerns completely.

I refer you to:

http://sources.redhat.com/ml/gdb-patches/2002-09/msg00319.html

Daniel's concerns are raised in:

http://sources.redhat.com/ml/gdb-patches/2002-09/msg00322.html

and I provided answers in:

http://sources.redhat.com/ml/gdb-patches/2002-09/msg00324.html

BTW I should point out that this patch is relative to another patch
I made to introduce openp_1() which implements openp() but allows
it to be immune to occurrences of DIRNAME_SEPARATOR which
can appear in the filenames embedded in the debugging information.

When this occurs, substitution into $cdir causes surprising
results!

This is a particular risk in Win32 environments because : can
occur in the context of filenames.

See

http://sources.redhat.com/ml/gdb-patches/2002-09/msg00317.html

for details.

Earl