This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] add -foverride-comp-dir
Mark Mitchell wrote:
Daniel Jacobowitz wrote:I see. Then perhaps the feature needs to be extended:
The other motivation for this kind of feature is so that you can
ship libraries in both object and source form, and make it easy for
users to refer to the source code in the debugger. You need to make
absolute paths into relative ones. Daniel, does GDB already have
the ability to do the substitution? In other words, does Dan's
functionality provide any additional leverage for that use case?
I'm not sure what you're asking. GDB has the ability to transform a
specified path into another path in source files. You have to get the
specified path into your objects somehow. We already know at least one
way to do this (the RPM debugedit tool, which we were talking about
using for our own packages too). Or you could do it in the compiler,
but then you have to make sure to compile everything with appropriate
What I think I was trying to ask was whether the new proposed switch
(or, Geoff's variant of it, where we totally omit the compilation
directory), would help with the "you have to get the specified path
into your objects somehow" issue. It sounded like it would help, in
that you could do -foverride-comp-dir=/canonical/path to ensure that
directory. However, I don't know if it's sufficient, in that you
really need to ensure that if you include "/foo/bar/baz.c", "/foo"
gets changed into "/canonical/path", but "bar/baz.c" is preserved. In
other words, the operation I'm after is to transform some
non-canonical path into a canonical path, so that users looking at the
debug information have a predictable path location.
The user will pass (for example):
The code that handles frebase-comp-dir performs a match-and-replace of
/home/user/work/src/project-root with '.'.
Thus, if a recursive-make build is used, you'd still get a canonical
path, for example:
gcc -g -c a.c -o a.o
should produces the path "./subdir/a.o" in the debug information.
Dan Aloni, Linux specialist
XIV LTD, http://www.xivstorage.com
email@example.com, firstname.lastname@example.org, email@example.com, firstname.lastname@example.org