If a function is defined after it appears in a TOC expression, we may
try to access an unset containing csect when returning a symbol for the
expression.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
- Build Status
Buildable 42586 Build 43109: arc lint + arc unit
Event Timeline
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp | ||
---|---|---|
1740 | for global ,I checked the gcc generated Functions Description as HIDDEN. |
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp | ||
---|---|---|
1740 | For static function, Digger is right, function descriptor symbol should have internal storage type. But for external linkage function, I think what Digger mentioned I checked the gcc generated Functions Description as HIDDEN should be interpreted as GCC generates two symbols for function descriptor, one is .csect foo[DS], the SD symbol has C_HIDEXT storage type, the other one is foo as a label within the csect which has C_EXT SC? And the label one plays the important role in GCC case to expose foo's function descriptor when the address of function is taken. So in LLVM, since we use the same symbol to represent the foo in .csect foo[DS] and the foo as label, I think the storage class here should follow the linkage type of function symbol, like: const XCOFF::StorageClass SC = TargetLoweringObjectFileXCOFF::getStorageClassForGlobal(GO); MCSectionXCOFF *FnDescSec = OutStreamer->getContext().getXCOFFSection( CurrentFnDescSym->getName(), XCOFF::XMC_DS, XCOFF::XTY_SD, SC, SectionKind::getData()); |
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp | ||
---|---|---|
1905 | can we implement as if (!XSym->hasContainingCsect()) { ....... XSym->setContainingCsect(Csect); } return XSym->getContainingCsect()->getQualNameSymbol(); |
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp | ||
---|---|---|
1740 | I agree with @Xiangling_L. The storage class should match that of the function symbol itself. |
This patch might need splitting. At least the commit subject should encompass the scope more. Once the tests are added for weak external or internal linkage, the "drive-by" change will be sizable.
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp | ||
---|---|---|
1902–1912 | The binding of "initialized" is unclear here. Do you mean "defined" functions? | |
1910 | Note regarding the linkage here as well. |
llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp | ||
---|---|---|
1740 | I agree. I originally intended to use getStorageClassForGlobal, but for some reason the XCOFF object file format document declares that CSects of mapping class have XMC_DS have storage class value of C_EXT. As noted this doesn't make much sense, so I will update this as described. | |
1905 | I'm thinking we may need to refactor how we setup containing csects for GlobalObjects in general. We end up duplicating the logic for what type of csect to create for a particular type of global in multiple places, and its not clear who owns setting up the containing csect (i.e. is it the first place we need the csect, or emitGlobalVariable and friends?). Perhaps getSymbol() could setup the containing CSect if it doesn't exist. Or maybe some type of getOrCreateContainingCsect(GlobalObject) function is more appropriate. Anyway, I'd like to address this in a follow on refactor patch, since this one is already getting large in scope. |
The scope of the "drive-by" change is heading into redesign territory.
llvm/test/CodeGen/PowerPC/aix-func-dsc-gen.ll | ||
---|---|---|
59 ↗ | (On Diff #232583) | This is not okay. There is already an external label definition with the same unqualified name. If we want to consider making the csect external, then we should stop creating the label. We will have to use a qualified name for the .globl in the assembly. |
I agree, I'm going to split the function descriptor change out and adopt the current mapping class of C_HIDEXT for this change.
- Remove function descriptor storage changes. They can best be reviewed in their own patch.
@daltenty, please update the commit message to indicate the corrected scope. This LGTM insofar as it fits the current handling of function descriptors for which we have a definition in the current object.
for global ,I checked the gcc generated Functions Description as HIDDEN.
for static function, I checked both gcc and xlc generated Functions Description as HIDDEN.