[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implementing CFSTR() in corebase

From: David Chisnall
Subject: Re: Implementing CFSTR() in corebase
Date: Fri, 22 Jan 2010 18:08:55 +0000

Richard wrote:

> Maybe you can initialize the 'isa' field to __objc_class_ref_NSConstantString 
> if you predeclare that some way?

Yes, that would be nice, wouldn't it?  Except that the GNU ObjC ABI doesn't 
work like that at all.  __objc_class_ref_NSConstantString is a linker symbol 
that points to the external symbol __objc_class_name_NSConstantString, which is 
emitted in the compilation unit containing NSConstantString.  
__objc_class_name_NSConstantString is NOT the address of the class, it is an 
unused integer.  The sole reason that these exist is to enforce ordering in the 
loader.  The loader will try to resolve these before calling the runtime 
initialization functions, which means that classes won't be initialised until 
the classes that they reference have been loaded (which is quite important).  
The symbol for the class is _OBJC_CLASS_NXConstantString, and it is not 
exported to the linker.

It's one of the things I intend to change in the new ABI, but I haven't done so 
yet.  The Apple runtime exports .objc_class_name_NSConstantString.  This starts 
with a ., so it doesn't pollute the C namespace, and can be referenced via an 
asm label if you really need it.

Stef wrote:

> I was hoping to take advantage of exactly that!  I'll go ahead and share 
> Fred's test (see attached files).  In this case, the NSConstantString struct 
> is compiled with {NULL, "myString", 8} (makes sense)... it's also in the 
> .date section (r/w) and not .rodate (r).  At some points that NULL gets 
> turned into a pointer to the NSConstantString class, and that's what I'd like 
> to be able to reproduce, if at all possible.

The NULL is not the important bit here - it's actually a compiler bug, and it 
should be set to "NSConstantString" for sanity checking if the compiler 
followed the ABI described in the runtime.  Of course, the GCC runtime was 
written by the same people as GCC, so expecting consistency is probably too 
much to ask for.

As I said, constant string references are all passed to the runtime via a 
structure containing an array of pointers.  The runtime looks up the class from 
the class name at the head of this list and sets it for all of them.

> Another issue is the reference counting.  GNUstep objects include a header 
> that has a NSZone * and integer for reference counting... does this need to 
> be reproduced.

Irrelevant.  Constant strings emitted by GCC don't have this.  It's incredibly 
frustrating, in fact, because it means that code everywhere needs special cases 
to take this into account (constant strings, protocols, and Classes can all 
crop up where objects are expected).  With the new ABI, there's a flag reserved 
in the class to indicate whether the class's instances are dynamically 
allocated, so you have a quicker test.

> David:
> Would setting CFSTR() to a function allow it to work in initializer?

Not a static initialiser, no, but that won't work on OS X either without a 
special case in the compiler.  Setting the length using strlen() is also not 
allowed, although at certain optimisation levels GCC might let you get away 
with it (clang won't).

> PS: I was hoping to come up with a solution that is at least halfway decent 
> without "requiring" compiler support (I don't have a new compiler to test it 
> with).

#define CFSTR(x) (@ x)

And require -x objective-c to be passed to the compiler when you compile C code 
that links to CoreBase...


-- Sent from my IBM 1620

reply via email to

[Prev in Thread] Current Thread [Next in Thread]