[LLVMdev] Linkage Types again!

Chris Lattner sabre at nondot.org
Sun Nov 23 19:08:01 PST 2003


On Sun, 23 Nov 2003, Brian R. Gaeke wrote:

> > That's essentially what I did to get it to work but instead of
> > appending, I just opted for LinkOnce.
>
> Sounds ok.

Note that appending linkage will do what you want, but the deal is that
you have to specify values to append together.  In the main translation
unit, instead of making it a strong symbol, make it either an appending or
external symbol.  The assertion you are now getting is correct: if you
don't specify an initializer, it must have external (only) linkage.  When
that xlation unit gets merged with an xlation unit that has appending,
linkonce, or strong linkage, it will keep the non-external linkage type.

> > > I don't quite understand why you need an appending global to do this, if you
> > > can only have one main. I would just set it to the correct initializer in the
> > > module that has main, and leave it external everywhere else.
> >
> > Its essentially a hack.  What I was trying to do was have the size of
> > the global stack array increase depending on the number of compilation
> > units that are linked together. The idea was that a given compilation
> > unit would know its stack requirements but not that of other compilation
> > units. Using appending linkage allows the sum total of the stack
> > requirements to be handled without foreknowledge of the total size
> > needed.

This should be implementable.  :)

> We do stuff like this with gccld, for C/C++ programs.

Also, on another note, it might be nice if the stacker "compiler driver"
took -O -O2, -O3, etc options.  There is no reason in particular for you
to use gccas/gccld: those tools are specific to the gcc frontend.  It's
possible that a different set of optimizations makes sense for stacker
than for C, for example.

*shrug*, anyway, it is _really_ cool that Stacker is in CVS.  :)

-Chris

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




More information about the llvm-dev mailing list