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: handling of absolute source file paths (feature wish/implementation idea)


Hello, Daniel!

On Thu, Jan 22, 2004 at 12:58:28PM -0500, Daniel Jacobowitz wrote:
> > > 3. Implement a new setting "source-absolute-prefix" (analog to the already 
> > > existing "solib-absolute-prefix") which allows the user to set a prefix for 
> > > given absolute source code paths.
...
>   src/include/elf.h
>   src/bfd/elfarm-nabi.c
>   src/bfd/elf32-arm.h
>   obj/bfd/bfd.h
> 
>   obj/bfd/elfarm-nabi.o:
>     compilation dir /blah/obj/bfd
>     path to source ../../src/bfd/elfarm-nabi.c
>     include flags -I. -I../../src/bfd -I../../src/include
> 
> I want to be able to issue one command and find elf32-arm.h,
> elfarm-nabi.c, bfd.h, and elf.h.  They all have relative paths, rooted
> at compilation directory /blah/obj/bfd.  It happens to have been moved
> to /blah-backup/obj/bfd and /blah-backup/src/bfd.

I can't see how source-absolute-prefix could help. If you set it to
/blah-backup, gdb would look for
/blah-backup/../../src/bfd/elfarm-nabi.c and wouldn't be able to find
it. If you set it to /blah-backup/obj/bfd and ask for
../../../src/gdb/cli/cli-cmds.c (compiled under /blah/obj/gdb/cli), gdb
would again not find it. How did you want to use it?


I think the problem is actually the fact that we use
gdb/source.c:openp() both for binaries and sources. For the former we
don't want to search the path if the name contains directory separators
due to the reasons discussed before in this thread. For the latter we
currently do the same; is it just because it is handled by the same
function, or are there any other reasons?

Seems that if we look for source files (both absolute and relative) in
the supplied path, we can use dir command to access the source trees
that were moved -- and this is, according to gdb 5.3 info documentation,
what dir command was intended for. As far as I could see, 1)
implementing source-absolute-prefix would also require this
rearrangement, 2) the case with trees moved deeper in hierarchy is the
only problem solved by source-absolute-prefix, and 3) it would be
already covered by dir if we process binaries and sources differently.

That is why I suggest that I modify openp so that it looks into search
path for source files (I'm thinking about replacing try_cwd_first with a
set of boolean flags determining the various aspects of the algorithm
and adding the respective flag for searching). What do you think?


With kind regards,
Baurjan.


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