Peter Collingbourne
2013-Mar-20 21:22 UTC
[LLVMdev] Hidden-visibility aliases to default-visibility globals
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
Joerg Sonnenberger
2013-Mar-21 05:12 UTC
[LLVMdev] Hidden-visibility aliases to default-visibility globals
On Wed, Mar 20, 2013 at 02:22:47PM -0700, Peter Collingbourne wrote:> 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 { ... }Have you tried using protected visibility? Joerg
Peter Collingbourne
2013-Apr-01 21:15 UTC
[LLVMdev] Hidden-visibility aliases to default-visibility globals
On Wed, Mar 20, 2013 at 02:22:47PM -0700, Peter Collingbourne 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.This is http://llvm-reviews.chandlerc.com/D606 Thanks, -- Peter
Peter Collingbourne
2013-Apr-01 22:49 UTC
[LLVMdev] Hidden-visibility aliases to default-visibility globals
On Thu, Mar 21, 2013 at 02:12:27PM +0900, Joerg Sonnenberger wrote:> On Wed, Mar 20, 2013 at 02:22:47PM -0700, Peter Collingbourne wrote: > > 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 { ... } > > Have you tried using protected visibility?Oops, missed this message. I think there was some reason why I thought protected visibility would not work, but I just tried it and it turns out that it does. I'll see what upstream thinks and if they're ok with it I'll drop the patch. Thanks, -- Peter
Rafael EspĂndola
2013-May-17 15:35 UTC
[LLVMdev] Hidden-visibility aliases to default-visibility globals
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
Maybe Matching Threads
- [LLVMdev] Hidden-visibility aliases to default-visibility globals
- [LLVMdev] Hidden-visibility aliases to default-visibility globals
- [LLVMdev] Hidden-visibility aliases to default-visibility globals
- RFC: Add guard intrinsics to LLVM
- Possible soundness issue with available_externally (split from "RFC: Add guard intrinsics")