[PATCH] Remove wild .debug_aranges entries generated from unimportant labels

[Eric Christopher]

On Wed, Oct 2, 2013 at 4:21 PM, Richard Mitton <richard at codersnotes.com>wrote:

> I'd rather keep it in. I'm sure gcc might not emit the arange table
> correctly, but the DWARF specs are quite clear that the idea of an arange
> table is to map *every* byte in the program to it's debug CU. Not just
> text. If there's a reference in the debug_info to an address, the arange
> table should have the reverse of that. This is why I used the label list to
> generate it, rather than trying to pick out functions/variables/etc. The
> labels added to debug_info define exactly the set of addresses required.
>
>
Data in general is fine to keep in, however, ...


> Common symbols have an address in the final program, so they should be
> included too.
>
>
This I'm going to disagree with, and the dwarf standard seems to back me up
here:

The table consists of sets of variable length entries, each set describing
the portion of the program’s address space that is covered by a single
compilation unit.

which says to me that the only items that should be included in the aranges
are items that are going to be unique to that compilation unit - which
would leave out common data. And a debugger can always use the symbol table
here anyhow. I don't know that we want a bunch of entries in the aranges
table that point to an address of 0 with a length of 1 - it doesn't strike
me as useful or desirable.


> Debuggers historically don't always use the full capabilities of the DWARF
> data, because the compilers don't generate correct data. If we fix the
> compiler here once and for all, it enables future debuggers to make use of
> it.
>
>
Heh. Except they won't, but I understand the point you're trying to make.
FWIW I'm attempting to get rid of pubnames and pubtypes as well.


> The biggest challenge faced by debuggers today is compilers which only
> emit barely enough DWARF to function. We can do better than that.
>
>
Agreed, somewhat. The problem is that they have to work with what they can
depend upon.

-eric


>   Eric Christopher <echristo at gmail.com>
>  Wednesday, October 02, 2013 2:35 PM
> *nod* The fix is fine.
>
> I think the additional complication that got us here is the adding of
> data symbols to aranges. Now, as far as I can tell, gcc doesn't emit
> aranges for any of them, however, the real problem for us are common
> symbols. I think we want to omit ranges for common symbols - it
> doesn't really seem to make sense anyhow.
>
> I know that gdb and the various gnu tools don't use that part of the
> information, but I don't know of any other users. So objections to
> removing that part? It'll definitely greatly simplify the code.
>
> -eric
>
>   Richard Mitton <richard at codersnotes.com>
>  Wednesday, October 02, 2013 2:00 PM
>  LGTM, although I dunno if I'm actually authorized to approve patches :)
>
> There's code in there already that ignores labels in metadata sections,
> but it wasn't getting triggered because debug_loc labels are added after
> the test for it. And the stupid sectionless common symbols mean that it
> couldn't just ignore NULL sections either.
>
> This looks like a fine fix.
>
> Richard Mitton
> richard at codersnotes.com
> On 10/02/2013 01:33 PM, Alexey Samsonov wrote:
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131002/2a67e87c/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131002/2a67e87c/attachment.jpg>