[cfe-dev] Running code on module load

[David Chisnall]

On 3 Mar 2008, at 22:02, Chris Lattner wrote:

> On Mar 3, 2008, at 9:17 AM, David Chisnall wrote:
>
>> On further inspection, there appears to be a bug in llvm-gcc when
>> performing this operation.
>>
>> The @llvm.global_ctors variable is defined as an array of i32,
>> function pairs (the i32 seems to always be 65536 - does anyone know
>> what this is?).
>
> That number is an initializer priority, which can be set with
> attr(init_priority) on some targets.  No LLVM targets do anything with
> it, so you can just set it to 65536.

Okay, I've done that for now it's MagicNumber.  We should probably  
reify that later...

>> Before I implement this in clang, I'd like to know if anyone knows  
>> the
>> correct behaviour.  Presumably the ctor functions should only be of
>> type void()*, since C doesn't provide any mechanism for handling
>> returns or passing in arguments to functions called in this way.
>
> Right.
>
>> Should we be silently casting ctor functions to this, or throwing an
>> error if they are of another form (could cause runtime errors if they
>> actually try to use their parameters)?
>
> Silently casting it is the right thing to do, and emitting a warning
> would also be great.  I wouldn't emit an error though.

Not done that yet, because it should probably be handled when building  
the AST.

>> Is there an accompanying linker bug?  What happens if you define the
>> @llvm.global_ctors as two different types in two different modules  
>> and
>> then try linking them?
>
> The front-end is required to make an array of type ["n" x { i32, void
> ()* }], so the bug is in the front-end.

Here's a patch which is trying to do that in the code generation.  Let  
me know if I've done anything completely silly, otherwise I'll start  
using this for registering things that call the Objective-C runtime  
functions (not tested - it's almost midnight here, and I need to sleep  
before writing more code).

David

-------------- next part --------------
A non-text attachment was scrubbed...
Name: clang.diff
Type: application/octet-stream
Size: 3336 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20080303/9d07a1dc/attachment.obj>
-------------- next part --------------