llvm dev - May 2013 - [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

On Mon, Apr 01, 2013 at 03:49:14PM -0700, Peter Collingbourne
wrote:
> 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.
Upstream didn't go for it [1] (for understandable performance reasons
[2], given that the dynamic loader will be linked into every executable
on the system).  Therefore, I'd like to ping my patch [3,4].

Thanks,
-- 
Peter

[1] http://sourceware.org/ml/libc-alpha/2013-05/msg00384.html
[2] http://www.airs.com/blog/archives/307
[3] http://llvm-reviews.chandlerc.com/D606
[4]
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130401/170206.html

> [2] http://www.airs.com/blog/archives/307
Note that it is not just efficiency. You actually get wrong results.
Without a marker like dllimport/dllexport used on windows, the
compiler can only guess if a symbol is on this module or not.

* One option is to be conservative and say it can be in another
module. In that case it will use the GOT to get the address of a
function, which is inefficient if the function is on this module. The
static linker could optimize this a bit. This is what OS X does
(symbols are effectively protected in there).

* The other option is to guess it is on the same module. The produced
code now has a relocation for a nearby entity (it is a 32 bit field),
and the best the dynamic linker can do is fill it with the GOT
address. This is what linux does.

You can observe the different strategies with the attached IL file:

$ ./build/bin/llc main.ll -mtriple=x86_64-apple-darwin -o - | grep foo
cmpq _foo at GOTPCREL(%rip), %rax
$ ./build/bin/llc main.ll -mtriple=x86_64-pc-linux-gnu -o - | grep foo
movl $foo, %ecx

There is an interesting article about this problem in
http://www.macieira.org/blog/2012/01/sorry-state-of-dynamic-libraries-on-linux.

I sometimes day dream of getting something like dllimport/dllexport on
ELF systems, but realistically I think the best we will get to is a
default like OS X with the push for position independent executables.

Cheers,
Rafael