[llvm-dev] [Proposal][Debuginfo] dsymutil-like tool for ELF.

[James Y Knight via llvm-dev]

On Mon, Aug 31, 2020 at 5:54 PM Fangrui Song <maskray at google.com> wrote:

> >>  1. Teach lld how to emit a separated debuginfo output file
> >>directly, without requiring an objcopy step.
>
> This is very similar to Solaris's ancillary objects (ET_SUNW_ANCILLARY).
> There are more details on
> http://www.linker-aliens.org/blogs/ali/entry/ancillary_objects_separate_debug_elf/
> In short, Solari's `ld -z ancillary[=outfile]` writes non-SHF_ALLOC
> sections to the
> ancillary object. Perhaps we will need some coordination with GNU. Some
> GNU folks are interested in a new object file type:
> https://groups.google.com/forum/#!topic/generic-abi/tJq7anc6WKs
>
>
> A debug file created by {,llvm-}objcopy --only-keep-debug has different
> contents (see https://reviews.llvm.org/D67137 for details):
> non-SHF_ALLOC sections and SHT_NOTE sections.
> http://www.linker-aliens.org/blogs/ali/entry/ancillary_objects_separate_debug_elf/
> does not say whether program headers are retained in the debug file, but
> {,llvm-}objcopy --only-keep-debug keeps one copy (neither gdb/lldb needs
> the program headers).


What I meant that lld should emit the same files you'd get via `objcopy
--strip-debug; objcopy --only-keep-debug; objcopy --add-gnu-debuglink` (or
`eu-strip -f foo.debug foo`). Only difference is that it's directly output
from the linker, instead of via a post-processing step. Could be invoked
like `ld.lld -o foo -s --debug-output=foo.debug`, or with `-S`, instead, if
you want to keep the symtab in the binary instead of the debuginfo.

The original GNU proposal for the new object type flag in that thread was
just a tiny modification of the existing formats, to enable identifying a
debuginfo file. We can easily implement that extra flag, if it happens.
It's not clear to me that introducing some other new behavior here would be
particularly interesting or useful -- even having seen that thread.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200901/55ca8b3c/attachment.html>