[PATCH] D105469: [Debug-Info] [llvm-dwarfdump] Don't treat DW_FORM_data4/8 to be section offsets in DWARF3.

[Paul Robinson via Phabricator via llvm-commits]

probinson added a comment.

In D105469#2861423 <https://reviews.llvm.org/D105469#2861423>, @shchenz wrote:

>> This means that DW_AT_byte_size can never point to a location list, and it was a bug to have it say it could (similarly for at least DW_AT_bit_size, and we probably should re-review the entire list). I suppose as an extension it could point to a location list, which would allow different size values based on the current execution address, although the only case I'm familiar with would derive the size from a variable, and so not have to have an actual location list.
>
> `DW_AT_byte_size` can not be a pointer to a location list, but it could be a `exprloc`/`block` kind location, so I guess it is ok to return true for `DW_AT_byte_size` in function `mayHaveLocationDescription()`. That function seems check for location descriptions for both `exprloc`/`block` kind location and also a location in `.debug_loc` section. See the function `dumpLocation()` when `mayHaveLocationDescription()` returns true.

Hmmm in that case the value is an expression that computes the value, not a location description.  There may be some looseness in the terminology in the code that could be tidied up.

> For `DW_AT_data_member_location` at DWARF3(default DWARF version for XCOFF), seems now we can not tell if the FORM_data4/data8 are for `loclistptr` or for `constant`. for the test case `formclass3-atmemloc.s`, it is a constant, so making it as location offset to the `.debug_loc` causes `llvm-dwarfdump` emit error message, I think we need to fix this. But if we always treat it as constant, it will also cause issue if the value is indeed an offset to `.debug_loc`. Maybe we have to find a way to differentiate FORM_data4/data8 for `loclistptr` and FORM_data4/data8 for `constant`.

The standard specifies that if an attribute allows one of the '*ptr' classes, then data4/data8 must be interpreted that way.  The interpretation is fixed for each attribute.  DWARF 3, section 7.5.4 "Attribute Encodings" third paragraph.  If the test is using data4 to encode a constant, the test is incorrect.  (I haven't really looked at the tests in this patch, except to see that they could probably be reduced quite a bit.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105469