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

[Richard Mitton]

It seems though that common symbols get converted into just regular BSS 
data upon link? (they do on my system at least). Common symbols seem to 
get assigned a valid address and size, not zero. I agree that writing 
out zero entries would be stupid, but that doesn't seem to be what we're 
doing.

I think I'd rather see the same address listed under two CUs (if it 
indeed appears in both CUs), than not at all.

(side note: IMHO llvm shouldn't really even support common symbols, 
surely comdat would be a better way of doing the same thing? And then we 
could emit debug_info chunks as comdat too and the problem would resolve 
itself. Well I can dream...)

Richard Mitton
richard at codersnotes.com

On 10/02/2013 05:53 PM, Eric Christopher wrote:
>
>
>
> On Wed, Oct 2, 2013 at 4:21 PM, Richard Mitton 
> <richard at codersnotes.com <mailto: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 <mailto: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 <mailto: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 <mailto:richard at codersnotes.com>
>>     On 10/02/2013 01:33 PM, Alexey Samsonov wrote:
>>
>>     _______________________________________________
>>     llvm-commits mailing list
>>     llvm-commits at cs.uiuc.edu <mailto: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/7b8f97a6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 1417b7a1a41d92ce_compose-unknown-contact.jpg
Type: image/jpeg
Size: 770 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131002/7b8f97a6/attachment.jpg>