gc-sections and DWARF ranges

[Cary Coutant]

> I found a test today where GDB fails to find symbol info.  It's not
> GDB's fault, though: there's an input .o file which has eleven entries
> in .debug_ranges, and then there's only nine by the end of the link.
> The tenth was for a GC'd section.  The eleventh, by bad luck, happens
> to be main.
>
> Cary fixed a specific case of this problem in GCC by emitting fewer ranges:
>
>  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42454
>
> That doesn't solve the general problem if there's actual garbage
> collection.
>
> Is there any provision in GNU ld for this that I'm not seeing?  We
> ought to remove discarded entries with knowledge of the .debug_ranges
> output; I don't see how we can get this right otherwise.
>
> I can make a good argument that every debug section with references to
> the discarded section must have special processing, or we are
> generating broken debug output - GDB's workaround for functions at
> address 0 is another case.  That one can be solved by use of section
> groups, but the compile unit's .debug_ranges has to be a single entity.

With gold, we don't observe the problem because it takes a pair of
zeroes to terminate the list, and gold still applies the addend when
applying a relocation that refers to a discarded symbol. In the
.debug_ranges section, for a function foo, we'll see relocations for
foo and foo+n. Where gnu ld relocates this to a (0,0) pair, gold
produces a (0,n) pair. Arguably, this isn't an ideal thing to do
either, but at least gdb doesn't get confused by the (0,n) entry.

As Richard said, ideally we'd never see a relocation to a discarded
section, as all those references would be in the same comdat group.

-cary