[PATCH] D70756: llvm-symbolizer: support DW_FORM_loclistx locations.

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

As for the test case: Yeah, I'd include the source (as minimal as possible) in a comment (along with whatever compiler command is used to generate the assembly from the source) & leave the assembly relatively unmodified from whatever LLVM produces - rather than trying to hand-craft it too much.

This is some of the shortest code I have that produces a loclist:

  void f1();
  void f2() {
    int i;
    f1();
    i = 2;
    f1();
  }

But maybe that doesn't produce the kind of location list you need? (I guess you need the variable to reside in memory/in the stack frame? in which case escaping the int as a poniter parameter (which, glancing through the DWARF in the test case, looks like what's going on)). You might be able to turn off the call site stuff (I'm not sure if there's a flag for it - I think there is) to reduce the DWARF a bit more.

(& yeah, I'm confused by the choice of comment character - all the assembly test cases I've seen/dealt with use '#' as the comment character)

As for the error handling - yeah, the absence of a DW_AT_location isn't an error case, but mangled DWARF that makes it impossible to resolve the location list (eg: a missing debug_addr section if address pool entry references are used) might be worthy of an error message. I don't think you need to handle this here and now, but I think it's possible that the "getLocations" API could be changed to return an empty non-error when the attribute is not present - in the same way as it could return an empty non-error if the attribute was present but referred to an empty location list (no DWARF producer should ever produce that) - it's just the degenerate case. Then the error cases would be really erroneous, I think, and might be worthy of reporting to a user.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D70756