This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: remapping absolute source paths


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]