[LLVMdev] Packages

[Chris Lattner]

On Mon, 17 Nov 2003, Reid Spencer wrote:

> On Mon, 2003-11-17 at 22:44, Chris Lattner wrote:
>
> > We already have never, ever, delete this flags.  "weak" and external
> > linkage both guarantee that.  If there can be an external caller of some
> > function, for example, the optimizer CANNOT delete it, nor can it change
> > it's interface.
>
> Interesting, I wouldn't have assumed that given LLVM's support for IPO.
> If you find that a function is never used when doing final linking of a
> program, why not delete it?  Just curious .. and off topic ..

Because it's not safe and could change the semantics of the program.  What
if you load a shared object that calls into the main program again: it
would break.

In practice the way we handle this is that we have an "internalize" pass
which marks all functions except main as 'internal'.  This lets the IPO
machinery do all of the things you would expect to the program, including
breaking it if it works like the above.  If this breaks a program, the
user can specify -disable-internalize on the linker command line.
Alternatively, they can specify a link-map to indicate exactly which
symbols should be exported.  FWIW, the LLVM runtime libraries use
link-maps extensively.

> > > If that was the case, I could use the full expression of LLVM assembly
> > > language to describe my source level information.  No?
> >
> > I'm not sure exactly what you mean here, but yes, in principle, you should
> > be able to do exactly that.  You are limited to the LLVM type system and
> > such, but if that is sufficient, yes.
>
> I just mean that I could define LLVM types to define the structure of my
> source level information. There actually isn't much that's needed. Some
> tables, a few bit masks, a couple structures to group things together.
> So, LLVM types are fine.

Yeah, ok.  Makes sense.

> > > This being the case, I could emit a function in each module that returns
> > > the source level information. To look at it, I just JIT load the module
> > > and call the function.  Any barriers to doing this?
> >
> > None at all!
>
> Not so fast! I have a couple issues I need your clarification on:
>
>       * The source level information could reference a function (in
>         fact, it would reference all of them!). Could this reference to
>         the function thwart optimization? Same for global variables,
>         types, etc.

Yes.  If you return a pointer to a function, for example, the optimizer
will have to assume that something outside of the module could call it...
If you represent the debug information as function bodies, also expect
that the body will be optimized as well.

>       * If I wanted to create a function named "GetModuleInfo" in every
>         module, wouldn't that cause link time symbol redefinition and
>         the resulting errors if it was "externally visible" linkage? If
>         I use weak linkage I avoid that problem, but then can I call the
>         function directly after JIT loading? Isn't it "internal" to the
>         module?

There is no good way to do this.  The best way is to do what we do for
static ctor/dtors: each ctor results in a new internal function being
generated to the .bc file.  Additinoally a pointer to this function is
added to an array with appending linkage.  The end effect is that you get
"appending" semantics for functions.

> (P.S. I read the entire discussion on "GCC tree linkage types" on the
> GCC list and got myself totally confused about what is and isn't
> "linkonce", etc.  Had to go back to the LLVM Language Reference to
> straighten myself out again :)

Heh, I'm still trying to get the mapping of GCC types to LLVM types
perfect.  :)

-Chris

-- 
http://llvm.cs.uiuc.edu/
http://www.nondot.org/~sabre/Projects/