[LLVMdev] RFC: Patch
Bill Wendling
isanbard at gmail.com
Sat Sep 22 16:02:50 PDT 2007
On Sep 22, 2007, at 10:57 AM, Chris Lattner wrote:
> On Sep 21, 2007, at 5:11 PM, Bill Wendling wrote:
>> My question is, is this liable to break something else down the line?
>> Should it be modified to call the getNamedGlobal method only if it's
>> an Objective-C property? Is this even the correct method for an
>> Objective-C property?
>
> There is a bigger question here. One invariant that is useful is
> that there is only a single decl that corresponds to a given global
> variable. It sounds like the objc front-end is making two GCC decl
> nodes for the same global variable? If so, is there a way to fix the
> objc front-end to merge them?
>
According to Fariborz, this is the correct behavior. This second time
through, it seems as if it's simply trying to do a lookup of the
(static) global variable "Foo". In essence, it's equivalent to this
code:
static struct S {
int i;
} Foo; // (1)
static struct S *Ref = &Foo; // (2)
When I run this through, we only get the "Foo" at (2) going through
the make_decl_llvm function and not the first one. I think that this
is because there isn't any metadata that needs to be attached to the
Foo object.
The code in objc/objc-act.c is acting like this: in finish_objc(), it
has:
if (protocol_chain)
{
if (flag_objc_abi == 2)
{
generate_v2_protocols (); /* (1) */
}
else
generate_protocols ();
}
/* APPLE LOCAL begin radar 4533974 - ObjC new protocol */
if (protocol_list_chain)
build_protocol_list_address_table ();
if (protocollist_ref_chain)
build_protocollist_translation_table (); /* (2) */
The call at (1) creates the metadata. It calls finish_var_decl(),
which creates the first decl. The call at (2) builds the reference
and also calls finish_var_decl(), which tries to do the lookup, but
fails because the first decl was marked "internal global". So it
tries to create a new decl, and kablooey. ;-)
The amount that I don't understand the obj-c code can fill
volumes. :-) We could ask Fariborz if merging them is possible. My
hunch is "no", but I could be wrong.
-bw
More information about the llvm-dev
mailing list