[PATCH] [ dwarfdump ] Add symbolic dump of known DWARF attribute values.

Frederic Riss friss at apple.com
Thu Sep 4 09:53:22 PDT 2014


================
Comment at: lib/DebugInfo/DWARFDebugInfoEntry.cpp:90
@@ +89,3 @@
+  
+  Optional<uint64_t> Val = formValue.getAsUnsignedConstant();
+  const char *Name = nullptr;
----------------
dblaikie wrote:
> Roll the "Val" variable into the if condition to reduce its scope:
> 
> if (Optional<uint64_t> Val = formValue.getAsUnsignedConstant())
>   Name = AttributeValueString(attr, Val.getValue());
> 
> (personally I prefer using the pointer-like interface of Optional (so I would write "*Val" rather than "Val.getValue()") but opinions differ and there's no solid convention in the codebase so far - so do whichever you prefer, I just mention it in case you aren't aware of it)
Will do. I wasn't aware of Optional::operator*. I'll use it.

================
Comment at: lib/DebugInfo/DWARFDebugInfoEntry.cpp:96
@@ +95,3 @@
+  if (Name) {
+      OS << Name;
+  } else {
----------------
dblaikie wrote:
> Mistaken indentation here? (looks like a 4 space instead of a 2, but it might be the review software being weird)
No the indentation is really off.

================
Comment at: lib/Support/Dwarf.cpp:799
@@ +798,3 @@
+
+const char *llvm::dwarf::AttributeValueString(uint16_t Attr, unsigned Val) {
+  switch (Attr) {
----------------
dblaikie wrote:
> dblaikie wrote:
> > As a follow-up, if you like, all these functions should /probably/ be modified to return StringRef, that way we don't have to compute their length later on (or do null-test walks) in printing functions, etc.
> Should the type of Attr be something more type-safe? (the actual enum of DWARF attributes)
I first wrote it like that, but I was finding the cast at the call site awkward. I can add it back, but we have no guarantee that the data we've read from the DWARF file will actually be a known Attribute, thus I find it more accurate to allow all values.

================
Comment at: lib/Support/Dwarf.cpp:829
@@ +828,3 @@
+
+  return nullptr;
+}
----------------
dblaikie wrote:
> This line is unreachable (so far as I can see?) and should be deleted.
> 
> (alternatively you could leave this one and remove the default case from the switch)
I actually wondered while writing the code if all supported compilers could correctly do the control flow analysis that proves that the second return is unnecessary. I added the default case to prevent warnings about missed cases when I was using a typed enum Attr, but now the default case can just go away.

http://reviews.llvm.org/D5187






More information about the llvm-commits mailing list