<div dir="ltr">On Wed, Oct 2, 2013 at 6:05 PM, Richard Mitton <span dir="ltr"><<a href="mailto:richard@codersnotes.com" target="_blank">richard@codersnotes.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<div>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.<br>
<br></div></div></blockquote><div><br></div><div>Yep. And we've got a relocation, at least for the common symbols, so they should get relocated at link time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div>
I think I'd rather see the same address listed under two CUs (if
it indeed appears in both CUs), than not at all.<br>
<br></div></div></blockquote><div><br></div><div>Fair enough. Given we don't have a consumer it seems like bloat/complexity for no use at the moment (much like column information unfortunately), but I'm not wedded to removing it either.</div>
<div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><div>
(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...)</div></div></blockquote><div><br></div><div>Mmm, type units will solve a huge chunk of the duplicate info problem, though we'd have to emit pieces of the arange table as comdat and not unique it? That sounds... complicated :)</div>
<div><br></div><div>At any rate, Alexey's patch still seems fine and we can go with that for now and discuss anything else later.</div><div><br></div><div>-eric</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div><span class="HOEnZb"><font color="#888888"><br>
<br>
<pre cols="72">Richard Mitton
<a href="mailto:richard@codersnotes.com" target="_blank">richard@codersnotes.com</a></pre></font></span><div><div class="h5">
On 10/02/2013 05:53 PM, Eric Christopher wrote:<br>
</div></div></div><div><div class="h5">
<blockquote type="cite">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Wed, Oct 2, 2013 at 4:21 PM,
Richard Mitton <span dir="ltr"><<a href="mailto:richard@codersnotes.com" target="_blank">richard@codersnotes.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">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.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Data in general is fine to keep in, however, ...</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Common symbols have an address in the final program, so
they should be included too.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>This I'm going to disagree with, and the dwarf standard
seems to back me up here:</div>
<div><br>
</div>
<div><span style="font-family:URWPalladioL;font-size:12pt">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.</span></div>
<div><br>
</div>
<div>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.</div>
<div> <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
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.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
The biggest challenge faced by debuggers today is
compilers which only emit barely enough DWARF to
function. We can do better than that.<br>
<br>
</div>
</blockquote>
<div><br>
</div>
<div>Agreed, somewhat. The problem is that they have to work
with what they can depend upon.</div>
<div><br>
</div>
<div>-eric</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<blockquote style="border:0px none" type="cite">
<div style="margin:30px 25px 10px">
<div style="display:table;width:100%;border-top-width:1px;border-top-style:solid;border-top-color:rgb(237,238,240);padding-top:5px">
<div style="display:table-cell;vertical-align:middle;padding-right:6px">
<img src="cid:part2.04040707.01050801@codersnotes.com" name="1417bd95e42367ab_1417b7a1a41d92ce_compose-unknown-contact.jpg" height="25px" width="25px"></div>
<div style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a href="mailto:echristo@gmail.com" style="padding-right:6px;font-weight:bold;color:rgb(115,127,146)!important;text-decoration:none!important" target="_blank">Eric Christopher</a></div>
<div style="display:table-cell;white-space:nowrap;vertical-align:middle">
<font color="#9FA2A5"><span style="padding-left:6px">Wednesday, October
02, 2013 2:35 PM</span></font></div>
</div>
</div>
<div>
<div style="color:rgb(136,136,136);margin-left:24px;margin-right:24px">
<div>*nod* The fix is fine.<br>
<br>
I think the additional complication that got us
here is the adding of<br>
data symbols to aranges. Now, as far as I can
tell, gcc doesn't emit<br>
aranges for any of them, however, the real
problem for us are common<br>
symbols. I think we want to omit ranges for
common symbols - it<br>
doesn't really seem to make sense anyhow.<br>
<br>
I know that gdb and the various gnu tools don't
use that part of the<br>
information, but I don't know of any other
users. So objections to<br>
removing that part? It'll definitely greatly
simplify the code.<br>
<br>
-eric<br>
<br>
</div>
</div>
</div>
<div style="margin:30px 25px 10px">
<div style="display:table;width:100%;border-top-width:1px;border-top-style:solid;border-top-color:rgb(237,238,240);padding-top:5px">
<div style="display:table-cell;vertical-align:middle;padding-right:6px">
<img src="cid:part2.04040707.01050801@codersnotes.com" name="1417bd95e42367ab_1417b7a1a41d92ce_compose-unknown-contact.jpg" height="25px" width="25px"></div>
<div style="display:table-cell;white-space:nowrap;vertical-align:middle;width:100%">
<a href="mailto:richard@codersnotes.com" style="padding-right:6px;font-weight:bold;color:rgb(115,127,146)!important;text-decoration:none!important" target="_blank">Richard Mitton</a></div>
<div style="display:table-cell;white-space:nowrap;vertical-align:middle">
<font color="#9FA2A5"><span style="padding-left:6px">Wednesday, October
02, 2013 2:00 PM</span></font></div>
</div>
</div>
<div style="color:rgb(136,136,136);margin-left:24px;margin-right:24px">
<div>
<div>LGTM, although I dunno if I'm actually
authorized to approve patches :)<br>
<br>
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.<br>
<br>
This looks like a fine fix.<br>
<br>
<div>Richard Mitton<br>
<a href="mailto:richard@codersnotes.com" target="_blank">richard@codersnotes.com</a></div>
On 10/02/2013 01:33 PM, Alexey Samsonov wrote:<br>
</div>
<br>
</div>
<div>_______________________________________________<br>
llvm-commits mailing list<br>
<a href="mailto:llvm-commits@cs.uiuc.edu" target="_blank">llvm-commits@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits</a><br>
</div>
</div>
</blockquote>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>