This is an archive of the discontinued LLVM Phabricator instance.

[llvm][IR] Add dso_local_equivalent Constant
ClosedPublic

Authored by leonardchan on Apr 1 2020, 3:35 PM.

Details

Summary

The dso_local_equivalent constant is a wrapper for functions that represents a value which is functionally equivalent to the global passed to this. That is, if this accepts a function, calling this constant should have the same effects as calling the function directly. This could be a direct reference to the function, the @plt modifier on X86/AArch64, a thunk, or anything that's equivalent to the resolved function as a call target.

When lowered, the returned address must have a constant offset at link time from some other symbol defined within the same binary. The address of this value is also insignificant. The name is leveraged from dso_local where use of a function or variable is resolved to a symbol in the same linkage unit.

In this patch:

  • Addition of dso_local_equivalent and handling it
  • Update Constant::needsRelocation() to strip constant inbound GEPs and take advantage of dso_local_equivalent for relative references

This is useful for the Relative VTables C++ ABI which makes vtables readonly. This works by replacing the dynamic relocations for function pointers in them with static relocations that represent the offset between the vtable and virtual functions. If a function is externally defined, dso_local_equivalent can be used as a generic wrapper for the function to still allow for this static offset calculation to be done.

See RFC for more details.

Diff Detail

Event Timeline

leonardchan created this revision.Apr 1 2020, 3:35 PM
leonardchan retitled this revision from [IR] Strip constant inbound GEPs when checking Constant::needsRelocation() to [IR] Update Constant::needsRelocation() to strip constant inbound GEPs and PLT relocations.
leonardchan edited the summary of this revision. (Show Details)
leonardchan added reviewers: phosek, mcgrathr.
leonardchan retitled this revision from [IR] Update Constant::needsRelocation() to strip constant inbound GEPs and PLT relocations to [llvm][IR] Add a new Constant, PLTEntry, which may represent the PLT entry for a function.
leonardchan edited the summary of this revision. (Show Details)
arsenm added a subscriber: arsenm.Aug 18 2020, 12:27 PM

Was there an RFC for this?

Missing GlobalISel support

leonardchan planned changes to this revision.Aug 18 2020, 12:29 PM

Was there an RFC for this?

Missing GlobalISel support

There hasn't, but I can send one out. The idea of a new constant was from discussing with @pcc offline.

Missing RFC + langref changes.

llvm/include/llvm/IR/Constants.h
891

What's PLT entry?

leonardchan edited the summary of this revision. (Show Details)

Clean up some of the code.

Also sent out an RFC at http://lists.llvm.org/pipermail/llvm-dev/2020-August/144469.html.

Still need to add and test GlobalISel support.

leonardchan planned changes to this revision.Aug 20 2020, 11:35 AM
leonardchan retitled this revision from [llvm][IR] Add a new Constant, PLTEntry, which may represent the PLT entry for a function to [llvm][IR] Add a new Constant (UnnamedFunc).
leonardchan edited the summary of this revision. (Show Details)

Update to reflect comments in the RFC.

Rather than "equivalent to the resolved function at runtime", I'd say "equivalent to the resolved function as a call target". It's not equivalent to the function at runtime when the runtime use is "ptr == &func".

This is just a naming suggestion, but how about naming it unnamed_func (instead of unnamedfunc) so it's closer to unnamed_addr.

leonardchan edited the summary of this revision. (Show Details)
  • Renamed unnamedfunc to unnamed_func.
  • Replaced "equivalent to the resolved function at runtime" with "equivalent to the resolved function as a call target".
  • Added section to LangRef.
leonardchan retitled this revision from [llvm][IR] Add a new Constant (UnnamedFunc) to [llvm][IR] Add dso_local_equivalent Constant.
leonardchan edited the summary of this revision. (Show Details)
leonardchan added a subscriber: rjmccall.

Updated to reflect the most recent comments at http://lists.llvm.org/pipermail/llvm-dev/2020-September/145177.html.

leonardchan edited the summary of this revision. (Show Details)Sep 23 2020, 5:25 PM
rjmccall added inline comments.Sep 23 2020, 10:03 PM
llvm/docs/LangRef.rst
3788

There has to be a type for the global in the syntax, right? Or is that an assumed prefix on this, and then we don't need it separately on the global because it's the same type?

Also, do we actually need the parens? I think the other places we use parens here, it actually does meaningful grouping.

On wording, allow me to suggest:

A '``dso_local_equivalent``' constant represents a global value which is functionally equivalent to a given global value, but is always defined in the current linkage unit.  The resulting pointer has the same type as the underlying global.  The resulting pointer is permitted, but not required, to be different from a pointer to the global, and it may have different values in different translation units.

The target global may not have ``extern_weak`` linkage.

``dso_local_equivalent`` can be implemented in several ways:

- If the global has private or internal linkage, has hidden visibility, or is ``dso_local``, ``dso_local_equivalent`` can be implemented as simply a pointer to the global.

- If the global is a function, ``dso_local_equivalent`` can be implemented with a stub that tail-calls the function.  Many targets support relocations that resolve at link time to either a function or a stub for it, depending on if the function is defined within the linkage unit; LLVM will use this when available.  (This is commonly called a "PLT stub".)  On other targets, the stub may have to be emitted explicitly.

- If the global is a variable, this can be implemented by copying the contents of the variable into the current linkage unit (as if by `memcpy`).  This is not supported on all targets, and target-specific restrictions may apply.  For example, on ELF this can be implemented as a copy relocation, which requires that the global has the same size at load time as it did at at link time.

I don't think you need to keep anything from the last paragraph.

leonardchan added a reviewer: rjmccall.
leonardchan removed a subscriber: rjmccall.
leonardchan added inline comments.
llvm/docs/LangRef.rst
3788

There has to be a type for the global in the syntax, right? Or is that an assumed prefix on this, and then we don't need it separately on the global because it's the same type?

The latter. I was aiming for a syntax similar to blockaddress, but we would know the global type since we still need to write it before dso_local_equivalent.

Also, do we actually need the parens? I think the other places we use parens here, it actually does meaningful grouping.

You're right. They can be removed.

Thanks for the suggestion also! The only thing I'd probably clarify on is if this constant accepts "global values" vs "global objects" since global value implies that this could also accept global aliases or global ifuncs. I suppose there's nothing wrong with this: ifuncs can have the same handling as functions, and depending on the aliasee, an alias can have the same handling as a function or variable. It could be that this is already implied, but I'll update to explicitly mention them also.

leonardchan edited the summary of this revision. (Show Details)Sep 24 2020, 12:28 PM
leonardchan edited the summary of this revision. (Show Details)Sep 24 2020, 12:28 PM

Previous diff was against HEAD rather than master. Updated.

Add generic lowering for targets that do not support PLTs.

I wasn't sure what the best way to lower the constant was, so I ended up making a module pass that runs before ISel and replaces dso_local_equivalents with dso_local stubs that tail call to the original function. I'm open to changing it if there's a cleaner way. I thought the easiest approach was to provide the generic implementation as IR that could be lowered naturally than through SDNodes in ISel.

pcc added inline comments.Oct 1 2020, 11:22 AM
llvm/docs/LangRef.rst
3814

I would make this specific to functions. I don't think this can be made to work with globals at least with existing ELF linkers because I don't think you can get the copy relocation behavior without the symbol's value being overridden by the linkage unit with the copy relocation, and it doesn't make sense to have more than one linkage unit override the address of the same global.

rjmccall added inline comments.Oct 1 2020, 3:37 PM
llvm/docs/LangRef.rst
3814

Oh, does ELF's copy relocation necessarily steal the symbol so that it resolves into the copying linkage unit? I thought it might be separable so that you could just get a local copy of the data without changing symbol resolution. That would be a much more generically useful feature.

pcc added inline comments.Oct 1 2020, 3:46 PM
llvm/docs/LangRef.rst
3814

I think the behaviors may be separable at the binary level (i.e. you could hand-craft an executable that only copies but doesn't override), but at the linker level the copying and overriding happen at the same time when the linker sees a non-GOT-generating relocation pointing to the symbol.

leonardchan added inline comments.Oct 1 2020, 7:08 PM
llvm/docs/LangRef.rst
3814

I'm fine with applying this to just functions for now since that was what I was initially planning to support. If possible, support for variables could be rolled out in the future. It looks like, off the bat, we could just use a GOT entry if we know the symbol is dso_local, but I think we can already achieve this by having a hidden global that points to your symbol.

Took me some time to research copy relocations, so correct me if I'm wrong, but should it be R_*_GLOB_DATA that overrides the symbol address during linking, whereas the copy relocation (R_*_COPY) just does the copying as @rjmccall suggests? I think it's R_*_GLOB_DATA that the GOT uses for getting addresses(?).

pcc added inline comments.Oct 1 2020, 7:22 PM
llvm/docs/LangRef.rst
3814

The R_*_COPY is normally generated by the linker and only present in the executable or shared object. It isn't present in an object file. The symbol address override is implemented by a symbol table entry, not by a relocation.

I'm not sure what would happen if you had an R_*_COPY in an object file without a definition of the symbol. You would need to make sure that it's passed through to the binary correctly and that dynamic loaders have the expected behavior (because normally dynamic loaders expect the symbol that's being copied to also be defined locally). The size of the symbol would also need to be known at compile time (as opposed to at link time in the normal case where the linker is inserting the relocation) in order to allocate enough space for the copy.

MaskRay added a subscriber: MaskRay.Oct 1 2020, 7:55 PM
MaskRay added inline comments.
llvm/docs/LangRef.rst
3814

I agree with pcc that the variable case should be dropped.

R_*_COPY could be used for shared objects in some ld.so (e.g. musl, which just skips the first definition; but not in glibc, which special cases that a COPY skips an executable definition). Generally it does not make sense for a shared object.

R_*_COPY on an executable copying its own symbol does not work -> the behavior is like RTLD_NEXT.

rjmccall added inline comments.Oct 1 2020, 10:55 PM
llvm/docs/LangRef.rst
3814

Is that avoidable? What happens if you ask for a copy relocation in an object file, or is that not expressible?

3814

I'm fine with just supporting functions given the absence of a target that can support this for variables.

3814

I thought I deleted this comment, but apparently not; please ignore it.

Update to only support functions since we don't have a fully flushed out way of supporting global variables.

leonardchan edited the summary of this revision. (Show Details)Oct 15 2020, 12:03 PM

ping, any more comments for this?

phosek accepted this revision.Oct 23 2020, 10:45 AM

LGTM but someone else should take a look as well.

llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
37 ↗(On Diff #295936)

Propagate

This revision is now accepted and ready to land.Oct 23 2020, 10:45 AM
leonardchan marked an inline comment as done.

*ping* for other comments. I'll probably commit this at the end of the week unless others have more to add.

MaskRay requested changes to this revision.Oct 27 2020, 9:19 PM

llc -filetype=obj doesn't. Please fix it. It is a bit unfortunate but the ELFObjectWriter generally has more restrictions than the assembler writer.

llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
2344
llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
24 ↗(On Diff #300376)
81 ↗(On Diff #300376)
83 ↗(On Diff #300376)

Shouldn't protected visibility use GV as well?

Is isDSOLocal implied by other properties?

llvm/test/CodeGen/X86/dso_local_equivalent.ll
39

_hidden_func{{$}}

44

ditto

49

ditto

54

ditto

72

ifunc stub may seem strange. Can you add a comment?

This revision now requires changes to proceed.Oct 27 2020, 9:19 PM
leonardchan marked 8 inline comments as done.

llc -filetype=obj doesn't. Please fix it. It is a bit unfortunate but the ELFObjectWriter generally has more restrictions than the assembler writer.

Ah, didn't see this. Yeah I was using this incorrectly in some of my tests. Fixed.

llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
83 ↗(On Diff #300376)

Yeah, it seems that there's actually a function that covers this already: GlobalValue::isImplicitDSOLocal.

llvm/test/CodeGen/X86/dso_local_equivalent.ll
72

Added. This is here mostly to ensure correctness since the ifunc may not be dso_local so we'd still need a stub to ensure that.

@MaskRay any more comments?

Updated some renamed variables that I didn't check prior.

Apologies for my late reply. A couple of comments inlined

See RFC for more details.

Neither the RFC nor the patch mentions the immediate use case. It is possible that the merit is buries in a deep message but for a few feature the description itself should justify its value (dblaikie mentioned that:

We should do this because I need it" (we shouldn't be implementing features for especially niche use cases/if they don't generalize) isn't always a compelling motivation but "we should do this because someone might need it" isn't either (we shouldn't be implementing features that have no users).

Please add the use cases.

llvm/include/llvm-c/Core.h
2171 ↗(On Diff #304667)

This is not defined. If you don't add a C implementation, please drop the declaration here and above

llvm/include/llvm/IR/Constants.h
892

The comment says "function" then "variable". Is "variable" a typo?

llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
20 ↗(On Diff #304667)
51 ↗(On Diff #304667)

ELF has comdat but does not need this pass.
Mach-O needs this pass but does not have comdat.

I assume that this code is untested.

llvm/test/CodeGen/X86/dso_local_equivalent.ll
5

This comment appears to be unrelated to the main purpose of the test. A file-level comment is needed to explain why darwin is picked (it does not support the lowering)

leonardchan marked 4 inline comments as done.

Apologies for my late reply. A couple of comments inlined

See RFC for more details.

Neither the RFC nor the patch mentions the immediate use case. It is possible that the merit is buries in a deep message but for a few feature the description itself should justify its value (dblaikie mentioned that:

We should do this because I need it" (we shouldn't be implementing features for especially niche use cases/if they don't generalize) isn't always a compelling motivation but "we should do this because someone might need it" isn't either (we shouldn't be implementing features that have no users).

Please add the use cases.

No worries. Thanks for the reviews! I added the use case in the LangRef. Essentially the immediate use case is for using static relocations in vtables under the new relative vtables ABI. This constant gives us a generic way to essentially "request" a PLT relocation from Clang without needing to explicitly say in the frontend "these targets support PLT entries".

llvm/include/llvm/IR/Constants.h
892

Yup, it should still be function. Fixed.

llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
51 ↗(On Diff #304667)

Added some cases for COFF where this pass is needed and comdats are supported.

leonardchan edited the summary of this revision. (Show Details)Nov 12 2020, 11:50 AM
leonardchan edited the summary of this revision. (Show Details)Nov 12 2020, 12:00 PM
MaskRay added inline comments.Nov 12 2020, 6:58 PM
llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
20 ↗(On Diff #304667)

Please use llvm::foo to define functions/variables in .cpp files

9 ↗(On Diff #304920)

Transform uses of dso_local_equivalent to a function stub for targets which do not support lowering dso_local_equivalent to MCExpr.

30 ↗(On Diff #304920)

Nit: Strings in assert usually do not need to end with a period

36 ↗(On Diff #304920)

I think the stub should be InternalLinkage (if you want to retain a symbol) or PrivateLinkage (if you don't want a symbol). You would not need hidden visibility below.

If you use a hidden function, and two translation units have dso_local declarations of the same function, the produced stubs will cause a duplicate definition error at link time.

llvm/test/CodeGen/X86/dso_local_equivalent.ll
11

-o - -> -o /dev/null

129

Use one single NO-PLT-NOT: .stub

145

Use one single NO-PLT-COMDAT-NOT: .stub

leonardchan marked 6 inline comments as done.
leonardchan added inline comments.
llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
36 ↗(On Diff #304920)

Hmm. I'm guessing the link error would only occur though if comdats weren't supported? In that case I think perhaps the stubs should be internal/private to avoid multiple definitions.

MaskRay added inline comments.Nov 14 2020, 10:34 AM
llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
36 ↗(On Diff #304920)

For stubs for declarations (not defined), there are some pitfalls. On ELF, if in a comdat, a hidden symbol works better because it can be merged with symbols in other translations; if not in a comdat, private/internal linkage has to be used to avoid linker issues. Such a comdat concept probably does not work on COFF. Mach-O does not have comdat.

The pass serves for binary formats which I think are not your main concern, am I right? :) If you cannot find people willing to review the Mach-O/COFF part, I recommend that you drop this pass from this patch because it is not needed by ELF (and your use case will condition the support on ELF anyway)

leonardchan added inline comments.Nov 16 2020, 10:21 AM
llvm/lib/CodeGen/DSOLocalEquivalentLowering.cpp
36 ↗(On Diff #304920)

Ah, ok I'll drop this pass then. The immediate use case for us is only ELF formats. I wasn't sure to what extent this should be supported for other binary formats, but I suppose those could be added down the line.

MaskRay accepted this revision.Nov 16 2020, 9:23 PM
MaskRay added inline comments.
llvm/include/llvm-c/Core.h
266 ↗(On Diff #305563)

Adding a member in the middle breaks prebuilt binaries linking against llvm-c. How about just dropping the change?

This revision is now accepted and ready to land.Nov 16 2020, 9:23 PM
leonardchan marked an inline comment as done.
leonardchan added inline comments.
llvm/include/llvm-c/Core.h
266 ↗(On Diff #305563)

Done. The only concern is that there is no generated value for this in the Value::ValueTy enum which would've led to some errors, so I added it manually with a comment explaining why it's there.

Welp, it turns out that if I went with the approach of adding the constant manually everywhere the macro was used, I'd be adding a lot of special cases everywhere. The only case I needed to cover was in Core which depends on Value.def:

/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-1/llvm/lib/IR/Core.cpp:832:12: note: expanded from macro 'HANDLE_VALUE'
    return LLVM##Name##ValueKind;
           ^
<scratch space>:239:1: note: expanded from here
LLVMDSOLocalEquivalentValueKind

The only way I could think of preventing the constant from being used here while still being used in other places HANDLE_VALUE/CONSTANT are used is a "banlist" approach via more macros in Value.def. Open to other ideas if it doesn't look that good.

This revision was landed with ongoing or failed builds.Nov 19 2020, 10:27 AM
This revision was automatically updated to reflect the committed changes.