https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109805
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rguenth at gcc dot gnu.org
--- Comment #4 from Richard Biener <rguenth at gcc dot gnu.org> ---
It works for the actual source file translation units for me, it's just the
LTRANS units that have a DW_AT_comp_dir that's not remapped. It's actually
difficult to do the right thing here and I think the correct thing to do if
you don't like the "bogus" DW_AT_comp_dir is to actually specify
-fdebug-prefix-map at link time.
The issue it's difficult to do the right thing is because you have to
consider
gcc -c t1.c -flto -fdebug-prefix-map=`pwd`=/aaaa
gcc -c t2.c -flto -fdebug-prefix-map=`pwd`=/bbbb
gcc t1.o t2.o
now, what DW_AT_comp_dir should the possibly single LTRANS CU use?
One "fix" might be to emit multiple DWARF CUs for each LTRANS unit and thus
keep the association to the original CUs 1:1 (I have some patches for this
lying around for a few years). But then we're still mixing CUs by means
of inlining and cloning.
Note the DW_AT_name of the LTRANS CUs is <artificial> (DWARF doesn't allow
to omit it). What's more "problematic" is that somehow the file list of
the CU contains t.c - it might be worth figuring out how this gets there.
A pragmatic fix could be to detect the case where all LTO inputs had the
same -fdebug-prefix-map specified and carry that over to link time
automatically in lto-wrapper (we are currently not streaming the various
remapping flags).
Can you clarify what the actual problem with the generated dwarf is?
