[llvm] r239560 - Object: Prepend __imp_ when mangling a dllimport symbol in IRObjectFile.

Peter Collingbourne peter at pcc.me.uk
Wed Jun 24 11:08:11 PDT 2015


On Tue, Jun 23, 2015 at 07:18:18AM -0400, Rafael EspĂ­ndola wrote:
> > --- llvm/trunk/test/Object/dllimport.ll (added)
> > +++ llvm/trunk/test/Object/dllimport.ll Thu Jun 11 16:42:18 2015
> > @@ -0,0 +1,17 @@
> > +; RUN: llvm-as %s -o - | llvm-nm - | FileCheck %s
> > +
> > +target datalayout = "e-m:w-i64:64-f80:128-n8:16:32:64-S128"
> > +target triple = "x86_64-pc-windows-msvc"
> > +
> > +; CHECK: U __imp_f
> > +; CHECK: U __imp_v
> > +; CHECK: T g
> > +
> > +declare dllimport void @f()
> > + at v = external dllimport global i32
> > +
> > +define void @g() {
> > +  call void @f()
> > +  store i32 42, i32* @v
> > +  ret void
> > +}
> 
> What should this do for
> 
> declare dllimport void @g()
> @gp = constant void ()* @g
> 
> Should there be an undefined reference to _g or _imp_g?

I think in this case we technically need both, as the actual symbol used
depends on how other modules use the constant (but as I mentioned in the
commit message, lld only needs one). For example:

1) Suppose that the only user of gp is an externally visible function that
   returns a pointer to gp.  In that case, the only reference is to g.

2) Suppose that the only user of gp is a function that loads the function pointer
   from gp and calls it. In that case, the optimizer could constant propagate
   the function pointer to the caller and make it a direct call, so the only
   reference would be to __imp_g.

> I am guessing
> both work since this is here just to cause the linker to fetch/keep
> all the necessary bits from other object files and archives and both
> undefined symbols will have that effect. In the end it will get a real
> object and that is when it has to construct thunks.

Exactly. Either reference will cause lld to synthesize both symbols, and
that is what will be used later on once lld has built the final object file.

> In any case, could you add that test with a comment?

r240562.

> But then again, if that is the case, why do we ever need to produce a
> _imp_* undefined symbol in here?

Dllimported global variables can only be referenced via a __imp_ symbol. It's
easier to be consistent when mangling these symbols.

Thanks,
-- 
Peter




More information about the llvm-commits mailing list