[PATCH] D58698: [DWARFFormValue] Don't consider DW_FORM_data4/8 to be section offsets.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Feb 26 14:55:19 PST 2019


dblaikie added inline comments.


================
Comment at: llvm/lib/DebugInfo/DWARF/DWARFFormValue.cpp:200
+    // In DWARF3 DW_FORM_data4 and DW_FORM_data8 served also as a section
+    // offset. If we don't have a DWARFUnit, default to the old behavior.
+    if (Form == DW_FORM_data4 || Form == DW_FORM_data8)
----------------
aprantl wrote:
> aprantl wrote:
> > "some producers" here means older versions of clang, but since older versions of clang also default to DWARF 2 (at least on Darwin) I think this is a safe change.
> To clarify: what we are dropping here is support for compilers that claim to emit DWARF 3+ but still is a FORM_data4 for a section offset. I'm fine with dropping support for these.
> 
> I'm not a fan of DWARFFormValue optionally having a DWARFUnit pointer. This is asking for trouble. If we could assert that we have on in this condition (or get rid of the optionality) I'd be much happier.
I mean... we could drop support for this convenience feature when dumping DWARFv3 and older entirely?


================
Comment at: llvm/test/tools/llvm-dwarfdump/X86/formclass2.s:3-4
+#   struct e {
+#     enum {} f[16384];
+#     short g;
+#   };
----------------
I'd consider making these both chars, just to make it clear that their type isn't interesting, perhaps.


================
Comment at: llvm/test/tools/llvm-dwarfdump/X86/formclass2.s:6-9
+#   e foo() {
+#     auto E = new e;
+#     return *E;
+#   }
----------------
I see this is necessary to produce a debug_loc section in the output. Perhaps that could be commented and/or maybe there's a more direct way to do it? (and/or maybe it'd be worth separating the need for a debug_loc section (& the code that tickles it sufficiently to occur) from the code that ensures 'e' is emitted in the DWARF)

Also - any idea why there's on an error emitted when debug_loc is present but too small? Should we emit an error even when it's not present? I mean, I can see the counterargument (could've stripped/objcopied this one section for test purposes, etc)

Also - 16384 seems rahter large. Any idea why the offset of 'g' must be /that/ large before the warning is emitted? oh... because it turns it into a data4, rather than a data2, etc. OK


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D58698/new/

https://reviews.llvm.org/D58698





More information about the llvm-commits mailing list