[PATCH] D66724: [AIX]Emit function descriptor csect in assembly

[Sean Fertile via Phabricator via llvm-commits]

sfertile added inline comments.


================
Comment at: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp:1724
+  // Emit a null environment pointer.
+  OutStreamer->EmitIntValue(0, PointerSize);
+
----------------
Xiangling_L wrote:
> sfertile wrote:
> > DiggerLin wrote:
> > > from the begin of the function to here, it actually emit a function description, can we add a new function and put the content into the new function and invoke the new function here ?
> > A good suggestion. I think we should take it a bit farther though. Add an `AsmPrinter::EmitDescriptor()` virtual function. Calling the base class implementation should be a fatal_error. Then somewhere we can explicitly check the MCAsmInfo if descriptors are needed, and call this new virtual if they are. My suggestion would be in `runOnMachineFunction`.
> Some description of function `EmitFunctionEntryLabel()`:
> 
> 
> > This is a virtual function to allow targets to do their wild and crazy things as required.
> 
> So my understanding is on AIX, we use this function to emit function descriptor as the comment specifies.
> 
> 
I think we are pushing past the limits of what the comment intended. I take it to mean 'the wild and crazy function entry point things`. The way the ELF V1 abi handles descriptors (with the entry point being a local symbol, and the descriptor being the global symbol) it kindof squeaks into this definition. For AIX we are emitting 2 distinct symbols, one of which has no relation to the function entry point symbol other then referencing its address.


================
Comment at: llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp:1762
+  StringRef TOC(".toc");
+  MCSymbol *TOCBaseSym = OutContext.getOrCreateSymbol(TOC);
+  MCSectionXCOFF *TOCBaseSection = OutStreamer->getContext().getXCOFFSection(
----------------
hubert.reinterpretcast wrote:
> Why are we naming a symbol `.toc` here and not really doing anything with it here or elsewhere in the patch?
Do we need a TOC symbol to represent the TOC base? Is the TOC base a csect with no contained symbol, or is it similar to the common csects where there is an implicit symbol with the same name contained in the csect? It seems like we really only need the symbol for our internal MC representation, in which case the name doesn't matter outside of being unique and not clashing with anything in the users namespace.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66724