[PATCH] Change representation of dllexport/dllimport

[Robinson, Paul]

> From: Nick Lewycky [mailto:nlewycky at google.com] 
> Sent: Thursday, September 12, 2013 11:43 AM
> To: Robinson, Paul
> Cc: Chandler Carruth; reviews+D1110+public+872068f434b7231c at llvm-reviews.chandlerc.com; llvm-commits
> Subject: Re: [PATCH] Change representation of dllexport/dllimport
>
> > On 11 September 2013 15:26, Robinson, Paul <Paul_Robinson at playstation.sony.com> wrote:
> > With the caveat that I didn't actually do the work, it looks like:
> > - We emit lists of dllimport/dllexport symbols to a linker-command
> >  section, conceptually similar to what Windows does.
> > - We invented a DLLExportLinkOnceLinkage for the special case of inline
> >  functions marked dllexport.  For this we added a new IR attribute.
> > - We fiddled a few places in lib/Target to get the right kinds of references
> >  to happen (relocs & which instruction is used). These look like some
> >  combination of ABI stuff and "do what the linker wants to see" stuff.
> >
> > Is that the kind of info you were looking for?
> >
> Yes, thanks. This is roughly what I was guessing -- a way of encoding the 
> exposed symbols list (see tools/gold/gold.exports for an llvm example) in 
> the source code.
>
> I do not understand how visibility is orthogonal to dllimport/dllexport. 
> I can't think of any way that hidden + dllimport/dllexport makes sense. 
> Neither does protected + dllimport, since there is no local copy of the 
> symbol to bind to (we're importing it). Protected + dllexport could make 
> sense, except that I don't see how it differs from protected (or on a 
> regular windows system, dllexport). The only combination that makes sense 
> is default + dllimport/dllexport.
>
> Could you give me an example where you'd actually want to use these 
> visibilities in combination?
> Nick

I understand where you're coming from, the first time somebody proposed
to dllexport a hidden symbol was a big double-take for me too.

Okay, for dllimport the visibility options are probably the same as any
other kind of external reference.

For dllexport, if you don't have an explicit export list, your linker/loader
is trying to infer exports based on visibility, and exporting a hidden
symbol is absolutely the wrong thing to do.  I get that.

For dllexport when you DO have an explicit export list, your linker/loader
isn't making any inferences; it knows a-priori what's visible outside the
boundaries of the DSO.  That means the "visibility" applies only to uses
_within_ the DSO.  Now let's postulate one TU that contributes to your DSO,
which defines utility functions for your exported API but aren't used
elsewhere within your DSO.  If those are visibility=default then they will
require GOT references (because you're compiling -fPIC, or at least I am)
even though you know there's no possibility that's actually needed within
the DSO.  But, if I make them visibility=hidden, the compiler can generate
cheaper shorter references without compromising the availability of the
symbol outside the DSO.  And the ELF visibility makes sense within the
boundaries of the DSO.  Everybody's happy.

So: because my target has an explicit export list, dllexport doesn't have
to imply anything special about visibility.

--paulr