[PATCH] D65240: [XCOFF][AIX] Generate symbol table entries with llvm-readobj

[Sean Fertile via Phabricator via llvm-commits]

sfertile added a subscriber: cebowleratibm.
sfertile added inline comments.


================
Comment at: llvm/include/llvm/Object/XCOFFObjectFile.h:162-167
+struct XCOFFSectAuxEntForDwarf {
+  support::ubig32_t SectionLength;
+  uint8_t Pad1[4];
+  support::ubig32_t NumberOfRelocEnt;
+  uint8_t Pad2[6];
+};
----------------
abrachet wrote:
> How do these and the other structs work? They have seemingly random padding that align these on non normal boundaries. Assuming this is the file format, why is there no need for `#pragma pack` or `aligans`? If we take just this type as an example 18 bytes worth of members, wont this be aligned by the compiler to 24 bytes?
> Assuming this is the file format, why is there no need for #pragma pack or aligans? If we take just this type as an example 18 bytes worth of members, wont this be aligned by the compiler to 24 bytes?

No: because none of the members used have an alignment greater then 1. `support::[u]bigN_t` types are 1 byte aligned, and the only other types used are char and uint8_t.

> How do these and the other structs work? They have seemingly random padding that align these on non normal boundaries. 

Most (maybe all) are described here: https://www.ibm.com/support/knowledgecenter/en/ssw_aix_72/filesreference/XCOFF.html#XCOFF__yaa3i18fjbau There is also a set of headers shipped as part of the OS that describes them but they are much harder to decipher. I'm not sure if the headers are available on the internet but hopefully @hubert.reinterpretcast  or @cebowleratibm  can point you to them if they are.

Each of them being 18 bytes in size is expected, once you know that and that there is no alignment restriction on the 2 and 4 byte types used the padding  layout should no longer seem so random.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D65240