How does the Mach-O loader load different NSString objects?

Question

I knew that if you define a bunch of @ "" NSString objects in the source code on Mac OS. These NSStrings will be stored in a segment in the Mach-O library.

Section sectname __ustring segname __TEXT addr 0x000b3b54 size 0x000001b7 offset 731988 align 2^1 (2) reloff 0 nreloc 0 flags 0x00000000 reserved1 0 reserved2 0 

If I have a binary hex dump, they align close together with 0x0000 as a delimiter. I want to know how the bootloader on Mac OS X loads these NSStrings when the program starts? Are they easy to load, recognizing the 0x0000 delimiter, or is it a line offset table somewhere else in the binary that points to individual NSString objects? Thanks.

(What I really want to do is increase the length of one of the NSString, so I need to know how the loader recognizes these individual objects)

added: I know if you define CStrings as @ "abc" in the code to be passed to the cstring segment. If it is a string of type @ "" "without ascii characters, it will be passed to the ustring section according to my digging.

Answer 1

There is a cstring section with all constant C strings. Each NSString constant refers to only one of these C strings. The C string for the NSString constant looks like this:

 struct NSConstantString { Class isa; char *bytes; int numBytes; }; 

See the __DATA __cfstring section.

Edit:

The __ustring segment is the equivalent of the __cstring segment, with the exception of UTF16 strings. Thus, a constant NSString can refer to ustring or cstring data.

The only link to ustring data is probably related to the cfstring used. If you lengthen one line, cfstring, referring to the next line, will refer to the tail of the elongated line, unless you correct it. You can find some free space elsewhere where you can point cfstring to.

Answer 2

Not. Each line has an address in binary format. If you insert a character in one line, the address will increase according to all of the above, and you will need to configure their addresses wherever they are mentioned in binary, plus if you make the segment large, you may need to adjust the location of any subsequent segments depending on how much packaging was there to align the segment. It is much easier to just recompile the program and let the linker take care of it.

NB NSStrings are not stored internally as sequences of C characters. This is an implementation detail, but I suspect that NSStrings use a character width of 16 bits.