[PATCH] Option to suppress the DWARF entries DW_AT_MIPS_linkage_name and DW_AT_linkage_name.

Wolfgang Pieb wolfgang_pieb at playstation.sony.com
Fri Sep 26 16:08:44 PDT 2014


Thanks for the comments, David.

================
Comment at: lib/CodeGen/AsmPrinter/DwarfUnit.cpp:45
@@ +44,3 @@
+static cl::opt<bool>
+SuppressLinkageNames("suppress-dwarf-linkage-names", cl::Hidden,
+                     cl::desc("Suppress the DWARF DW_AT_(MIPS_)?linkage_name entries"),
----------------
echristo wrote:
> dblaikie wrote:
> > I believe we're trying to move away from surfacing command line flags in this way for user-facing features. (see Chris Bieneman's work).
> > 
> > I'm not sure what the right answner is these days - this could be a flag on the compile_unit metadata - in which case it could be properly respected under LTO (if one CU was built with the flag and one built without it, it'd be possible/practical/easy to respect those differences, emitting linkage name for one CU and omitting it in another).
> It's definitely a code gen option and so should go on a code gen option struct. That said, we're probably getting enough of them that a sub struct for debug info would be better.
> 
> i.e. I don't see why we'd want to handle adding or subtracting on a CU basis and thus need to put it on the metadata.
Using a flag on the CU metadata is definitely preferable due to LTO. It also avoids cluttering up the command line, since we want to suppress the attributes unconditionally anyway (without breaking the existing debuginfo tests that check for them). I'll scratch the current change and start over.


================
Comment at: test/DebugInfo/suppress-linkage-entry-4.ll:8
@@ +7,3 @@
+; The test checks whether the DWARF linkage name attributes are suppressed (DWARF 4).
+; The IR was generated with 'clang -gdwarf-4' from the following source:
+
----------------
dblaikie wrote:
> What's the important distinction between this test and the previous one? It looks like we've only got one codepath so I'm not sure if we need two test cases.
Right, I was vainly trying to catch future dwarf-3/dwarf-4 deviations, but it doesn't seem worth it.

http://reviews.llvm.org/D5510






More information about the llvm-commits mailing list