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

Sean Fertile via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 6 13:49:33 PDT 2019


sfertile added inline comments.


================
Comment at: llvm/include/llvm/Object/XCOFFObjectFile.h:152
+  support::ubig32_t IndexOfNextEntry;
+  char Pad[2];
+};
----------------
We should open a defect against the XCOFF object file docs, it list the pading as length 1 which is incorrect.


================
Comment at: llvm/lib/Object/XCOFFObjectFile.cpp:462
+uint32_t
+XCOFFObjectFile::getSymbolIndex(const XCOFFSymbolEntry *SymbolEntPtr) const {
+  return SymbolEntPtr - SymbolTblPtr;
----------------
sfertile wrote:
> I think this is the wrong interface for this function.  Taking a pointer to an `XCOFFSymbolEntry`  ends up making us cast a bunch of symbol table entries to a type they clearly are not to get their Symbol index. Instead we should take a unitptr_t.
Looks good. One suggestion is to have some error checking similar to what we have in `checkSectionAddress` .


================
Comment at: llvm/lib/Object/XCOFFObjectFile.cpp:649
+  int16_t SectNum = getSectionNumber();
+  Expected<DataRefImpl> SI = OwningObjectPtr->getSectionByNum(SectNum);
+  if (!SI)
----------------
jasonliu wrote:
> sfertile wrote:
> > If we fail to find a section, then should a StorageMappingClass of `XMC_PR` be enough to determine the symbol is a function?
> In a single .o file, then maybe XMC_PR is enough to determine the symbol is a function. 
> But I'm not sure if that's the case for a executable/dynamic library where linker could regroup the functions in a different way.  
> I'm open to suggestions if there is a better way to do this.
Sorry, I don't have any helpful suggestions. I'm not familiar enough with XCOFF to know when/how it uses absolute symbols.  I think this current implementation is OK for now. It might lead to missing information in llvm-readobj but we can refine it as our understanding grows. 


================
Comment at: llvm/lib/Object/XCOFFObjectFile.cpp:125
+      XCOFFSymbolEntry::NAME_IN_STR_TBL_MAGIC)
+    return generateStringRef(CFileEntPtr->Name, XCOFF::NameSize);
+
----------------
We can remove the second argument to `generateStringRef` and use `XCOFF::NameSize` directly in the implementation, since all calls use the same value for the argument.


================
Comment at: llvm/lib/Object/XCOFFObjectFile.cpp:647
+  const XCOFFCSectAuxEnt *CSectAuxEnt = getXCoffCSectAuxEnt();
+  // The symbol is label define.
+  if ((CSectAuxEnt->SymbolAlignmentAndType & SYM_TYPE_MASK) != XCOFF::XTY_LD)
----------------
`label define` --> `label definition`.


================
Comment at: llvm/test/tools/llvm-readobj/xcoff-symbols.test:1
+# RUN: llvm-readobj --symbols %p/Inputs/aix_xcoff_xlc_test8.o | \
+# RUN: FileCheck --check-prefix=SYMBOL32 %s
----------------
Add the source used, compiler, and options used to genetrate the object file in a comment.

Also it seems that we have added several constructs that are not exercised in the test: Block Aux Entry, Dwarf Aux Entry, Function Aux Ent. If these aren't tested then remove them from this patch and we can add them in a subsequent patch.


================
Comment at: llvm/tools/llvm-readobj/XCOFFDumper.cpp:236
+  switch (SC) {
+  case XCOFF::C_EXT:
+  case XCOFF::C_WEAKEXT:
----------------
We are adding a bunch of cases which aren't tested. Would it be better to add these cases with an assert  and implement them in a future patch which also adds the missing test coverage? 


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

https://reviews.llvm.org/D65240





More information about the llvm-commits mailing list