Comment 1:

Thanks for raising this issue. This machine belongs to adg.

Comment 2:

My current diagnosis is that the Darwin linker on 10.6 has a bug.  It does not correctly
handle a X86_64_RELOC_UNSIGNED relocation with a size other than 64 bits.  You can see
the bug at line 4592 of
http://opensource.apple.com/source/ld64/ld64-95.2.12/src/ld/MachOReaderRelocatable.hpp .
 It does an unconditional 64-bit load regardless of the relocation length.  It then
checks to see that the loaded address is within the target section.
6l is using 32 bit addresses to load variable addresses.  This is unusual on a 64-bit
system but it works fine provided the linker always puts the code in the low order 32
bits of the address space.  Unfortunately this triggers the bug in the Darwin linker.
In 10.7 the linker appears to have been completely rewritten, and it no longer has this
bug.
One possible fix would be to change 6l to convert MOVQ from an absolute address to use
RIP-relative addressing instead.  That would continue using a 32-bit address, but would
produce a relocation that the Darwin 10.6 linker can understand.  I don't know how
complex that would be.  I also don't know if there are other cases that would have to be
addressed.

Comment 3:

Note that I've already added the necessary PIC changes to 6l, guarded by the -shared
flag. I suppose darwin (10.6) could re-use the PIC mode, but since RIP-relative
addressing excludes other useful addressing modes the resulting code size will grow,
which is probably not an acceptable tradeoff.

Comment 4:

Note that I've already added the necessary PIC changes to 6l, guarded by the -shared
flag. I suppose darwin (10.6) could re-use the PIC mode, but since RIP-relative
addressing excludes other useful addressing modes the resulting code size will grow,
which is probably not an acceptable tradeoff.

Comment 5:

Considering the increasingly few people who a) use 10.6, b) run servers or otherwise
care about the binary size or performance on 10.6, I wouldn't worry about it.

Comment 6:

Either way I think it might be useful to use RIP addressing when possible--when there is
no indexing or scaling.  I think the resulting instruction will be one byte shorter.

Comment 7:

This issue was closed by revision 3197be4.

Status changed to Fixed.