[PATCH] D77248: [llvm][IR] Add dso_local_equivalent Constant

[John McCall via Phabricator via llvm-commits]

rjmccall added inline comments.


================
Comment at: llvm/docs/LangRef.rst:3784
+  may need to be emitted explicitly.
+- If the global is a variable or alias to a variable, this can be implemented
+  by copying the contents
----------------
pcc wrote:
> rjmccall wrote:
> > pcc wrote:
> > > 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.
> > 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.
> 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.
Is that avoidable?  What happens if you ask for a copy relocation in an object file, or is that not expressible?


================
Comment at: llvm/docs/LangRef.rst:3784
+  may need to be emitted explicitly.
+- If the global is a variable or alias to a variable, this can be implemented
+  by copying the contents
----------------
MaskRay wrote:
> pcc wrote:
> > leonardchan wrote:
> > > rjmccall wrote:
> > > > pcc wrote:
> > > > > rjmccall wrote:
> > > > > > pcc wrote:
> > > > > > > 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.
> > > > > > 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.
> > > > > 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.
> > > > Is that avoidable?  What happens if you ask for a copy relocation in an object file, or is that not expressible?
> > > 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(?).
> > 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.
> 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.
I'm fine with just supporting functions given the absence of a target that can support this for variables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77248