[Bug ld/18836] ld handles .gnu.lto_ prefixed sections oddly, /DISCARD/ semantics unclear

[rguenth at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=18836

--- Comment #13 from Richard Guenther <rguenth at gcc dot gnu.org> ---
The descripion in comment #12 is mostly correct as to the design and its
constraints.  Slight corrections below.

At compile-stage with -flto we generate early-debug information to be
consumed by the LTRANS output link.  We also generate a separate set of
full debug (early+late) for the FAT part of the compile-stage object.

Yes, the LTO parts are supposed to be dropped when doing a FAT link,
and yes, this was one reason to choose the .gnu.lto_ prefix.

As for using a linker script to do the job of extracting and renaming
the early-debug sections from the compile-stage objects I was hoping
to avoid extra I/O and direct the linker to do that job when it links
the LTRANS output objects.  GNU ld seems to be happy to take a linker
script as linker-plugin output (but we run into that section flag issue
at least).


Now for the current "workaround" I still use a linker-script and
a partial link to do the section copying/renaming (but I still can't
get rid of the 'E'xclude flag other than by linking an artifical object
with debug-info sections not containing that flag - GNU ld seems to
make sure a non-'E'xclude flag prevails if present on any input).
Of course doing that partial link separate from the LTRANS object link
involves extra I/O and disk-space.



Note that "going this far" wasn't very difficult - in fact the approaches
simplicity is why I chose it.  The approach was also extensively discussed
last year in the discussion about early-debug.

Now if those implementation issues wouldn't exist...  esp. that
'E'xclude flag as puts in on the section drives me crazy.  I think I
can "fix" the linker script doing the incremental link to also work
with gold but it would of course be nice to avoid creating that extra
(large) output file.


As for using split-dwarf I did not want to start going on the route
to effectively "split" the compile-time objects because I am sure
we'll run into tooling issues with existing makefiles when we start
doing that.  Note that an additional constraint on the setup is
that incrementally linking the compile-time objects has to work
(the kernel does that), not sure what happens to split-dwarf here.
split-dwarf is also not generated early but together with late debug.
And we'd still need to link the .dwo files back into the executable
because split dwarf is not something we can force to all of our users.

-- 
You are receiving this mail because:
You are on the CC list for the bug.