Open Radar

 
* Summary

Currently, the automatically activated data reordering functionality from Xcode 3.2's ld64 causes programs generated by our compiler to crash.

To solve this problem, and to prevent similar problems from happening in the future, I would like to ask for an assembler directive to either designate
a) symbols that must not be reordered by the linker, or
b) a group of symbols that must remain together in the original order at all times

Furthermore, and this is very important to us, it should be possible to use something like the following:

.if __NO_REORDER_SYM_SUPPORTED__
.noreorder sym1
.noreorder sym2
.noreorder sym3
.endif

This way, we can output code that will correctly assemble no matter which version of "as" our user is using.


Explanation:

Our compiler has support for a language features called "resource strings". Each string has a unique identifier, which makes them easy to replace with translated versions (much like the translation strings in plists).

The resource strings themselves are collected per unit in a table with the following structure in the assembler file:

***
.data
 global_unitx_start_label:
 [metadata]

 global_string1_label:
 [string 1 data]

 global_string2_label:
 [string 2 data]

 global_unitx_end_label:
***

I.e., there are global start and end symbols, and in between each string is also identified by a global symbol. This enables easily referring the string values from inside other compilation units.

The compiler also adds an array to the main program that collects references to all of these start and end labels:

.globl  FPC_RESOURCESTRINGTABLES
FPC_RESOURCESTRINGTABLES:
       .long   1                        // number of start/end pairs
       .long   global_unitx_start_label
       .long   global_unitx_end_label

When the program ends, code walks over this array and subsequently over all resource strings between the start and end labels to finalise the values assigned during run time.

It is clear that for this to work, the start and end labels as well as the individual resource string symbols must remain in their original order.

When compiling a dynamic library under Mac OS X 10.6, ld notices that the data following the start label and all string labels contains relocations and hence moves them to the start of the data section (as explained in the ld man page comments for the -no_order_data option). The end label remains behind, and as a result the code crashes when it walks over the array to finalise it.

What I therefore would need is a way to specify in the assembler file that particular symbols must not be reordered by the linker.

I can work around this particular problem by simply adding a dummy relocated value after the end label (then it will be moved along with the rest). I assume however that LD will become more aggressive regarding all kinds of reordering in the future, and this workaround will probably break at that moment.

I know about the "-order_file" linker parameter, but it is too blunt: I'm not interested in telling the linker *where* it should put this data, only that it should either leave it alone or keep it together.


* Steps to reproduce

Unpack the attached archive, then (x86_64 code)
1) cd ldreorderdata
2) ./build.sh -no_order_data
3) nm liblib.dylib |grep '_RESSTR_P\$TEST'|sort
4) ./prog
5) ./build.sh
6) nm liblib.dylib |grep '_RESSTR_P\$TEST'|sort
7) ./prog


* Expected results

The symbols displayed by nm should all be exactly 32 bytes (0x20 bytes) apart.

Furthermore, twice the following output from "prog":

firststring
secondstring


* Actual results

When linked with -no_order_data, everything is fine.

When linked without -no_order_data, the address for the end symbol is wrong:

00000000000269c0 D _RESSTR_P$TEST_START
00000000000269e0 D _RESSTR_P$TEST_FIRSTSTRING
0000000000026a00 D _RESSTR_P$TEST_SECONDSTRING
0000000000026c50 D _RESSTR_P$TEST_END

(0x26c50 - 0x26a00 == 0x250 != 0x20)

Due to this problem, the program crashes with a bus error:

$ ./prog 
firststring
secondstring
Bus error


* Regression

The problem does not occur with versions of Xcode before 3.2 (except possibly in the iPhone SDK), because they did not reorder data.


* Notes

I've worked around it in a currently unreleased version of our compiler by adding a relocated value after the end label. As mentioned in the summary, I assume things may however break again if ld starts reordering more aggressively.

Another possible workaround, as demonstrated in above, is to use -no_reorder_data. Since our compiler also runs on Mac OS X 10.3, that is not a very inviting approach since we'd somehow have to detect first whether the linker supports this option.