[LLVMdev] Hidden-visibility aliases to default-visibility globals

Rafael EspĂ­ndola rafael.espindola at gmail.com
Fri May 17 08:35:57 PDT 2013

I think this is a bug in global opt. We should probably not consider
this a correctness issue in general, but

* It is fine for something low level like a dynamic linker to depend
on some implementation details.
* This is not profitable. Global opt should figure out that accesses
via a hidden alias are faster than via a non-hidden symbol and avoid
the transformation.

On 20 March 2013 17:22, Peter Collingbourne <peter at pcc.me.uk> wrote:
> Hi,
> I am trying to compile a dynamic loader using LLVM.  Part of the IR
> for this loader looks like this:
> @_rtld_local = hidden alias %struct.rtld_global* @_rtld_global
> @_rtld_global = unnamed_addr global %struct.rtld_global { ... }
> The purpose of _rtld_local is to allow _rtld_global to be referenced
> without using the GOT, as this global is accessed before the dynamic
> loader initialises the GOT.  However, LLVM sees through the alias
> and resolves references to _rtld_local to _rtld_global, resulting in
> segfaults when the dynamic loader is used.
> I'm trying to figure out the best way to fix this.  The
> GlobalValue::mayBeOverridden() function controls whether LLVM resolves
> aliases, and hacking this function to return true if a global is hidden
> gets around this particular problem, but converts the function into a
> misnomer (a hidden alias may _not_ be overridden, e.g. by LD_PRELOAD,
> although I'm pretty sure mayBeOverridden is not intended to care about
> LD_PRELOAD) and results in a lot of deoptimisation.  I'm thinking
> of introducing a new function GlobalAlias::mayBeResolved() which
> returns true if mayBeOverridden() returns false and the visibility
> of the alias is the same as that of the aliasee, and converting over
> the relevant clients of mayBeOverridden to use this new function.
> Thanks,
> --
> Peter
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

More information about the llvm-dev mailing list