Macho dynamic linking

[nobody]

How can I generate position independent assembly under NASM targeting the macho object file format for use in a shared library?

Is it possible to do this in NASM?? If not, are there any workarounds or plans to implement this??

A simple "hello word" example would be much appreciated.

[Frank Kotler]

Sorry, I'm only certified for beginner questions. :)

As you know, the macho format is new to Nasm, and not yet well-documented. I know almost nothing about it, and very little about PIC. There's a section in the Manual on writing shared libraries for Linux/BSD, which may or may not apply to macho. In "outmacho.c", I see a reference to "pcrel", but I don't know how to use it.

Here's a newbie example (for Linux) that finds the data - "pretending", in this case, to not know...

;------------------
global _start

section .text
_start:

jmp get_data_address
got_data_address:
pop ecx
mov edx, msg_len
mov ebx, 1
mov eax, 4
int 80h

mov eax, 1
int 80h

section .data

get_data_address:
call got_data_address
msg db "hello word [sic]", 10
msg_len equ $ - msg
;--------------------------

I thought we'd need to put the data in the ".text" section - which would make it read-only, but it works with some code in ".data", too. I really don't think that's "right!

The same technique should work in macho, but I don't see how it'll help with anything that needs to be declared global or external.

I'll try to get you a better answer...

Best,
Frank

[nobody]

Thankyou very much Frank for your help.

"Mach-O position-independent code design is based on the observation that the __DATA segment is always located at a constant offset from the __TEXT segment. That is, the dynamic loader, when loading any Mach-O file, never moves a file’s __TEXT segment relative to its __DATA segment. Therefore, a function can use its own current address plus a fixed offset to determine the location of the data it wishes to access. All segments of a Mach-O file, not only the __TEXT and __DATA segments, are at fixed offsets relative to the other segments."

"Note: If you are familiar with the Executable and Linking Format (ELF), you may note that Mach-O position-independent code is similar to the GOT (global offset table) scheme. The primary difference is that Mach-O code references data using a direct offset, while ELF indirects all data access through the global offset table."

The above is an extract from http://developer.apple.com/documentation/DeveloperTools/Conceptual/MachOTopics/Articles/dynamic_code.html

The section in the manual relating to writing shared libraries for Linux/BSD is elf/a.out specific and does not work for macho (as the above quotes allude to).

Performing ggc -S -fPIC hello_world.c produces a .s file with a similar style to the example you gave in regards to the fact that it references a label defined in the .data section from the .text section to get the data address.
The problem with this is the fact that ld (mach object file link editor) errors out with the following message: ld: object_file.o has local relocation entries in non-writable text section (__TEXT,__text). This can only mean that the object file generated by NASM is still not position independent.

Putting code in the .data section works but this a big NO NO and is not correct.

I thank-you for helping me with this problem, much appriciated.