[PATCH] D126257: Round up zero-sized symbols to 1 byte in `.debug_aranges`.

David Blaikie via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu May 26 11:47:59 PDT 2022


dblaikie added a comment.

In D126257#3539510 <https://reviews.llvm.org/D126257#3539510>, @DavidSpickett wrote:

> In https://reviews.llvm.org/rG38eb4fe74b38 I moved the generic test into the X86 folder as it uses an X86 triple. You could think of the folder names there having 2 meanings, 1: the tests look at things specific to that arch and 2: they use that arch's triple (I think X86 is usually the one people choose if they want to test something generic anyway).

Thanks for the catch/cleanup!



================
Comment at: llvm/test/CodeGen/Generic/dwarf-aranges-zero-size.ll:18
+!0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression())
+!1 = distinct !DIGlobalVariable(name: "EXAMPLE", linkageName: "EXAMPLE", scope: null, file: null, line: 161, type: !2, isLocal: false, isDefinition: true, align: 1)
+!2 = !DIBasicType(name: "()", encoding: DW_ATE_unsigned)
----------------
bjope wrote:
> Notice that align here is specified in bits. I think it is a bit weird to have a 1 bit alignment?
> 
> So why do I care? Our downstream fork is checking that alignment is a multiple of byte size since the getAlignInBytes methods in DebugInfoMetadata.h is dividing the alignment specified in bits by the byte size. This test case hit such assertions.
> 
> Do you think it is ok to change this to "align: 8"?
Guessing we could probably just remove the "align: " field entirely here.

Usually I'd advocate for generating the example from some C++ source code fed into clang, since that's the most canonical IR we have - a small example with a zero-length array or the like. Though that might lead to more type information than is really helpful in a test like this.

I guess this was generated by Rust? So might be worth seeing why/where this alignment was created, maybe there's some bugs there to be sorted out too.

As for the alignment restrictions: Might be worth upstreaming your check into LLVM's debug info verifier to make it an explicit constraint of the IR - would make it easier to detect these sort of things sooner.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126257



More information about the llvm-commits mailing list