https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70428
hongxu jia <hongxu.jia at windriver dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #4 from hongxu jia <hongxu.jia at windriver dot com> ---
(In reply to jos...@codesourcery.com from comment #3)
> On Wed, 30 Mar 2016, hongxu.jia at windriver dot com wrote:
>
> > Do you mean the combination of using *"relative path" source to compile*
> > and *"absolute path" in -fdebug-prefix-map to remap* is not proper?
>
> It's perfectly proper. But the absolute path passed to -fdebug-prefix-map
> must be the actual pwd of the build or an absolute path passed to the
> compiler, or a prefix of one of those. It must not be some canonicalized
> version that was never seen by the compiler and combines fragments of
> paths handled differently by the compiler. I don't think the compiler
> ever does anything with a path such as /folk/hjia/test1/test2, or ever
> interprets what "../../" means in the path to source files. You need to
> pass /folk/hjia/dir1/dir2 or a prefix thereof to -fdebug-prefix-map in
> your example, and the resulting debug info will still contain references
> to ../../test1/test2/test.c (so you need to make sure that the remapped
> path is one relative to which ../../test1/test2/test.c is valid, on the
> system where the debug info is interpreted).
Ok, thanks to point it out
