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
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?
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 prefix- map=`pwd` =/bbbb
gcc -c t2.c -flto -fdebug-
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?