This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] add -foverride-comp-dir
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Mark Mitchell <mark at codesourcery dot com>, Geoffrey Keating <geoffk at apple dot com>, Dan Aloni <da-x at monatomic dot org>, gcc-patches at gcc dot gnu dot org
- Date: Sun, 01 Oct 2006 19:05:35 -0700
- Subject: Re: [PATCH] add -foverride-comp-dir
- References: <20060926135209.GA3599@localdomain> <firstname.lastname@example.org> <45201FAF.email@example.com> <20061001232746.GA12846@nevyn.them.org>
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
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.
(650) 331-3385 x713