[PATCH] D134195: [PowerPC] XCOFF exception section support on the integrated assembler path

[Digger Lin via Phabricator via llvm-commits]

DiggerLin added inline comments.


================
Comment at: llvm/lib/MC/XCOFFObjectWriter.cpp:797
+                     is64Bit() ? SymbolRef.getVisibilityType()
+                               : SymbolRef.getVisibilityType() | 0x0020,
+                     SymbolRef.getStorageClass(),
----------------
pscoro wrote:
> DiggerLin wrote:
> > we emit the xcoff object code as old interpret (SymbolRef.getVisibilityType() | 0x0020). ? 
> > 
> >  if we want to interpret as old version what about the code in line 818.
> > 
> >  
> > ```
> > writeSymbolEntry(SymbolRef.getSymbolTableName(),
> >                      CSectionRef.Address + SymbolOffset, SectionIndex,
> >                      SymbolRef.getVisibilityType(),
> >                      SymbolRef.getStorageClass());
> > ```
> We ran into an issue where this feature would not work without the 0x0020 bit set, which according to the documentation is part of the old xcoff implementation. It would make sense that the OR 0x0020 should be added to line 818 as well, but first I need to double check that my understanding is correct. Am I correct that this `void XCOFFObjectWriter::writeSymbolEntryForCsectMemberLabel` function is called with `const Symbol SymbolRef`s that are always function symbols? If this is the case, then I can add the 0x0020 to line 818 as well.
> Am I correct that this void XCOFFObjectWriter::writeSymbolEntryForCsectMemberLabel function is called with const Symbol SymbolRefs that are always function symbols?

I think when -fdata-section is off, A global data symbol also enter into the function.  You can write test case and test it.






Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134195