[llvm-dev] unified debug information despite function/data sections flags

David Blaikie via llvm-dev llvm-dev at lists.llvm.org
Wed Sep 29 23:51:43 PDT 2021


You can differentiate dead function descriptions from others on most
platforms by checking if the low_pc == 0. If 0 is a valid instruction
address on your architecture, you can use an lld feature to set a more
authoritative/unambiguous tombstone value for dead code addresses, passing
something like:

* -z 'dead-reloc-in-nonalloc=.debug_ranges=0xfffffffffffffffe'
** -z 'dead-reloc-in-nonalloc=.debug_loc=0xfffffffffffffffe'
*
* -z 'dead-reloc-in-nonalloc=.debug_*=0xffffffffffffffff'*

to the linker.

As for reducing debug info size by omitting debug info descriptions of dead
code - Apple/MachO's dsymutil does this, and I believe Alexey Lapshin is
working on trying to get similar behavior into lld, possibly (or as a
post-link tool).

There's also the possibility of using comdats to make the linker's job
easier - I think there might be ways to structure the DWARF into chunks
that could be deduplicated and dropped naturally by a linker's existing
comdat support, but I haven't fully prototyped it. I think there was a
thread a while back with JHenderson and others discussing this possibility
further.

- Dave

On Wed, Sep 29, 2021 at 12:50 PM Youssefi, Anna via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> Hi,
>
>
>
> I was wondering if there are any plans to separate debug information into
> distinct sections accordingly when the compiler flags -ffunction-sections
> and/or -fdata-sections are used.  If an unreferenced function is removed
> from the link, it makes no sense for its associated debug information to
> still be included.  As we rely on the debug information for stack usage
> analysis, we wind up displaying stack usage statistics for unreferenced
> functions that were eliminated from the link if debug information for any
> other referenced functions is in the same debug section.  It seems that
> others have run into this problem previously so I wanted to check whether
> there are any plans to change the behavior.
>
>
>
> Thanks,
>
> Anna Youssefi
>
> Texas Instruments, Codegen group
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210929/5ba871dd/attachment.html>


More information about the llvm-dev mailing list