gcc

Bug #2019160
Comment #9

Comment 9 for bug 2019160

Revision history for this message

In GCC Bugzilla #109805, Sergio Durigan Junior (sergiodj) wrote on 2023-05-11:

(In reply to Richard Biener from comment #4)
> 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?

Thanks for the reply.

I understand the problem here. But taking the vim package as an example, the remapping was done to a specific directory, for all object files.

> 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).

That'd solve the problem I'm seeing, I believe.

> Can you clarify what the actual problem with the generated dwarf is?

If we take the vim package as an example (again), the problem I'm seeing is that -fdebug-prefix-map is being used when compiling all .o files, but the generated binary ends up with the old path in its directory table. This confuses debuginfod, which uses this information to determine where the source files are located. It's interesting to note that I also see the new path listed in the DWARF, but for some reason debuginfod/GDB get confused about it.

I found yet another package that seems to be affected by this problem: samba. Curiously enough, there are other packages that don't seem to be affected, even though they're also being compiled using LTO.

(In reply to Richard Biener from comment #4)
> 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?

Thanks for the reply.

I understand the problem here.  But taking the vim package as an example, the remapping was done to a specific directory, for all object files.

> 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).

That'd solve the problem I'm seeing, I believe.

> Can you clarify what the actual problem with the generated dwarf is?

If we take the vim package as an example (again), the problem I'm seeing is that -fdebug-prefix-map is being used when compiling all .o files, but the generated binary ends up with the old path in its directory table.  This confuses debuginfod, which uses this information to determine where the source files are located.  It's interesting to note that I also see the new path listed in the DWARF, but for some reason debuginfod/GDB get confused about it.

I found yet another package that seems to be affected by this problem: samba.  Curiously enough, there are other packages that don't seem to be affected, even though they're also being compiled using LTO.