[cfe-dev] Running code on module load

[David Chisnall]

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?).  However, the functions can have arbitrary types.  The  
following code will break llvm-gcc:

int __attribute__((constructor)) foo(void) {
   return 0;
}
void __attribute__((constructor)) bar(void) {}

Worse, it doesn't give a nice warning, but an internal LLVM error  
because the first method defines the type of the array and the second  
being added (with a different type) breaks everything.

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.   
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)?

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?

David

On 2 Mar 2008, at 15:29, David Chisnall wrote:

> Hi,
>
> Most of the remaining parts of Objective-C code generation require
> code to be run when the module loads (calling runtime library
> functions to register the existence of classes, categories, protocols,
> and so on).
>
> Looking at llvm-gcc, it seems that I need to put these in
> @llvm.global_ctors to have them automatically put in the .ctors
> section in the compiled module.  Does clang already have some
> infrastructure for collecting these and emitting the list?
>
> David
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev