[PATCH] D105916: [AsmPrinter][CallGraphSection] Emit call graph section
Necip Fazil Yildiran via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jul 22 15:16:02 PDT 2021
necipfazil added inline comments.
================
Comment at: llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1293
+ enum FunctionKind {
+ NOT_INDIRECT_TARGET = 0,
+ INDIRECT_TARGET_UNKNOWN_TID = 1,
----------------
MaskRay wrote:
> Move this outside and make it clear that the section consumer needs to synchronize with the values.
Done. Please see `AsmPrinter::FunctionInfo`.
================
Comment at: llvm/lib/MC/MCObjectFileInfo.cpp:1046
+ GroupName, true, ElfSec.getUniqueID(),
+ cast<MCSymbolELF>(FunctionSym));
+}
----------------
MaskRay wrote:
> necipfazil wrote:
> > MaskRay wrote:
> > > getStackSizesSection uses getBeginSYmbol on TextSec.
> > Could you please provide more information on the requested change?
> >
> > When the section is linked to `getBeginSymbol(TextSec)` (i.e., `getBeginSymbol(TextSec)` is passed as the last argument to `getELFSection()` call), we still experience issues with garbage collection:
> >
> > ```
> > `.text.FUNCNAME' referenced in section `.callgraph' of OBJFILE.o: defined in discarded section
> > ```
> >
> > Therefore, I am passing function symbol as parameter to `getCallGraphSection()` so that we can link the newly created section to it.
> >
> > Where else do we need to use `getBeginSymbol()`?
> You may need to provide instructions to reproduce the linker error.
>
> The .stack_sizes scheme definitely works. If not, the current code must miss some stuff.
Thanks for the clarifications.
Looks like emitting call graph section later in `AsmPrinter::doFinalization()` was the issue.
`MCObjectFileInfo::getCallGraphSection()` now has almost the same logic as `MCObjectFileInfo::getStackSizesSection()`, with only difference at the section name. Do we need to share logic between two?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D105916/new/
https://reviews.llvm.org/D105916
More information about the llvm-commits
mailing list