mach-o objfmt, amd64 relocation issues

[Peter Johnson]

On Fri, 5 Jan 2007, Henryk Richter wrote:
> impatient as I am, I was unwilling to wait for the 0.7.0 milestone and 
> started
> a mach-o objfmt by myself. Please don't shoot me for the ugly code as I am 
> not too
> familiar with yasm's internals and possibly replicated redundant 
> functionality.
>
> I got basic 32 bit mach-o files working with text, data and bss sections. The
> relocations still need some work, currently basic pointers, absolute symbols
> and common vars seem to operate. Other relocations like WRT, PC-relative
> and such are untested/inoperable.
>
> My main problems, however start in 64 bit mode. So far I've got a simple test
> application running which correctly interfaces with 64 bit code in certain 
> conditions.
> I can instruct the mach-o format to reloc 64 bit absolute addresses
> (like in "mov rax,qword _somelabel"), calls are working but I need some
> ideas to support such constructs as "mov rax,[_some_label]. The x86-64
> implementation of mach-o seems to be heavily RIP-relative so that
> "movq rax,[rip+_some_label" works but I cannot see how to assemble the
> former symbol type (see attached reloc.h.gz). A reloc like "R_X86_64_32" as
> present in ELF is not known to me.

Great work so far!  Looking at reloc.h, it appears that the equivalent of 
R_X86_64_32 is X86_64_RELOC_SIGNED, which the header file claims is "for 
signed 32-bit displacement".  Perhaps the difficultly you're running into 
is that RIP-relative displacement in NASM syntax is specified using not 
movq rax, [rip+_some_label] but movq rax, [_some_label WRT rip].  The 
reason for this is that the additive notation is very confusing.  The GAS 
parser jumps through some hoops to make _some_label(%rip) translate into 
the WRT form.

Peter