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

Esme Yi via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jul 8 02:04:50 PDT 2021


Esme added a comment.

In D105469#2860046 <https://reviews.llvm.org/D105469#2860046>, @probinson 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.
>
> Similarly, DW_AT_count can never point to a location list, with the same caveat as for DW_AT_byte_size.

I am trying to split this patch into 2 patches. 
I have post the first one D105613 <https://reviews.llvm.org/D105613> to handle the bug that we try to dump the location list for those attributes that don't have localist class.

> 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.)

The test was compiled from a c++ source code, and the overflow error does exist for DW_AT_data_member_location in DWARF3.
Do you mean that we should use other forms to encode a constant in DW_AT_data_member_location?
I will have a look into the issue and post another patch for it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D105469



More information about the llvm-commits mailing list