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 thecorrect 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 andthen 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
clang.diff
Description: Binary data
_______________________________________________ cfe-dev mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
