This is the mail archive of the mailing list for the GCC 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: [PATCH] add -foverride-comp-dir

Daniel Jacobowitz wrote:

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 flags :-)

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.

Mark Mitchell
(650) 331-3385 x713

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