<div dir="ltr">If anything like this is going to be done - I suspect the right place to discuss it is on the DWARF committee (or at the very least, crossposted between llvm-dev and lldb-dev with all the Usual Suspects of debug info support included (echristo, aprantl, Paul Robinson, myself))</div><br><div class="gmail_quote"><div dir="ltr">On Thu, Mar 30, 2017 at 3:59 AM George Rimar via Phabricator <<a href="mailto:reviews@reviews.llvm.org">reviews@reviews.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">grimar added a comment.<br class="gmail_msg">
<br class="gmail_msg">
In <a href="https://reviews.llvm.org/D31464#713928" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D31464#713928</a>, @jhenderson wrote:<br class="gmail_msg">
<br class="gmail_msg">
> Generally looks okay to me. I've made a few inline comments.<br class="gmail_msg">
><br class="gmail_msg">
> This approach works for .debug_ranges, because we are working with pairs of addresses, but we have to be more careful with other DWARF sections, because on some architectures, address zero is a valid address and should not be used, and we cannot simply set the size to zero, because we don't know where that is (if anywhere at all). gdb recognizes zero as special, if the architecture does not allow zero addresses, but otherwise it is not treated as special, and so we end up with (potentially) overlapping debug info entries which can cause problems with the debugger. Similarly, .debug_aranges uses an address and a fixed size, which we have to update correctly. There's a related discussion on the LLDB mailing list I started about handling GC'ed sections in the debugger: <a href="http://www.mail-archive.com/lldb-dev@lists.llvm.org/msg04140.html" rel="noreferrer" class="gmail_msg" target="_blank">http://www.mail-archive.com/lldb-dev@lists.llvm.org/msg04140.html</a>. The general agreement is that we should use a special non-zero address. I would suggest -1 (i.e. 0xFFFFFFFF in 32-bit DWARF addresses and 0xFFFFFFFFFFFFFFFF in 64-bit DWARF addresses), but we should have that discussion on the mailing lists.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
Interesting. I worried about other sections and so this patch touches only .debug_ranges. Thanks for your comments !<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
================<br class="gmail_msg">
Comment at: ELF/InputSection.cpp:487<br class="gmail_msg">
<br class="gmail_msg">
+static bool isDiscardedSection(SymbolBody &Body) {<br class="gmail_msg">
+  DefinedRegular *D = dyn_cast<DefinedRegular>(&Body);<br class="gmail_msg">
----------------<br class="gmail_msg">
jhenderson wrote:<br class="gmail_msg">
> Should be called isInDiscardedSection, because it is working with a symbol not a section. "isDiscardedSection" suggests to me that it is asking if a section has been discarded or not, and so would take an InputSection or section index.<br class="gmail_msg">
I agree.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
================<br class="gmail_msg">
Comment at: ELF/InputSection.cpp:510<br class="gmail_msg">
+<br class="gmail_msg">
+  bool IsDebugRanges = Name == ".debug_ranges";<br class="gmail_msg">
   for (const RelTy &Rel : Rels) {<br class="gmail_msg">
----------------<br class="gmail_msg">
jhenderson wrote:<br class="gmail_msg">
> Is there anywhere else that we check section names? If so, I'd personally prefer if we set some flag on the section early rather than doing string comparisons on every input section to test the name multiple times.<br class="gmail_msg">
This method is isolated and used for doing relocations for non allocatable things like debug sections.<br class="gmail_msg">
I would not let this a bit wierd but reasonable logic to go outside.<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<a href="https://reviews.llvm.org/D31464" rel="noreferrer" class="gmail_msg" target="_blank">https://reviews.llvm.org/D31464</a><br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
</blockquote></div>