[LLVMdev] Packages

[Reid Spencer]

On Mon, 2003-11-17 at 23:18, Chris Lattner wrote:
> >
> >       * 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.

That's fine. I probably wouldn't return a pointer to function but a
pointer to structure that contains the information. Getting the function
that builds that structure optimized is just a bonus :)

> 
> >       * 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.

Yeah, I could use the same approach. A single array with appending
linkage would be all I needed to access every module's information. This
would work out well.

Thanks for your help on this. I think I can now see clearly a way to
retain my source level information directly in the byte code. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20031118/e8911206/attachment.sig>