Author Topic: Mach-o relocations  (Read 6511 times)

Offline clockworkd

  • Jr. Member
  • *
  • Posts: 10
Mach-o relocations
« on: September 03, 2020, 04:29:01 AM »
Okay so I have a really arcane problem!
I’m writing a compiler for macOS  that outputs nasm code. I just added DWARF debugging output to the Linux version, all went fine but I’m struggling with the macOS version.
First of all when I compile a C program with Apple’s own tool chain, all functions that actually get called have relocations generated for them automatically. I understand that these relocations are referenced by an offset in the Mach-o header.
Obviously this is my own compiler so I don’t know how to encode the relocations - since nasm is generating the Mach-o header and I don’t have access to it or a way to influence what nasm does.
You may wonder why this even matters... well, Apple’s dsymutil appears to detect that there are no relocations on these functions, assumes they aren’t getting called, and so discards all of my carefully crafted DWARF information!
The above is what I THINK is happening. I can’t say for sure. I managed to patch dsymutil to force it to pass the DWARF through, but that brought other problems. And I don’t like maintaining patched versions of parts of LLVM.
Has anyone got any suggestions about what I should do?
Thank you!

Offline clockworkd

  • Jr. Member
  • *
  • Posts: 10
Re: Mach-o relocations
« Reply #1 on: September 09, 2020, 07:18:14 PM »
Right well I patched nasm to make it generate “intra-section” relocations and Apple’s dsymutil still complains of “no valid relocations”. So I now think that dsymutil expects relocations in the DWARF data itself. Since I’m generating my own DWARF data and there’s apparently no way to control nasm’s behaviour in this regard, I’m going to have to do everything manually. So I’m going to add a command line switch to nasm so my compiler can tell it what relocations on debug_info it should generate. I won’t submit this to the nasm project because as I said it’s pretty arcane and probably only of use to me.
By the way, Apple added some extensions to DWARF/Mach-o... nasm should really be supporting the new section names (for example ‘.apple_names’ and ‘.apple_types’). I had to patch nasm to do that also.
Wish me luck!

Offline Frank Kotler

  • NASM Developer
  • Hero Member
  • *****
  • Posts: 2667
  • Country: us
Re: Mach-o relocations
« Reply #2 on: September 09, 2020, 08:03:40 PM »
Good Luck, clockworkd!


Offline clockworkd

  • Jr. Member
  • *
  • Posts: 10
Re: Mach-o relocations
« Reply #3 on: September 17, 2020, 02:00:29 PM »
I'm posting this patch here for anyone who might need it. It makes nasm behave more nicely with Apple's tooling. Specifically, it:
  • Adds support for Apple's new section names (".apple_names" etc.).
  • Adds a new pseudo-instruction called "reloc" whose purpose is to generate a relocation at the current assembly location (Apple's dsymutil won't work properly without this). The relocation will always point to the ".text" section. This provides a way to output relocations inside DWARF data.
  • Adds a new command-line option, --discard-labels, which causes nasm to discard any non-essential labels (good for clarity in debugging).
Please note the patch can only be applied to nasm 2.15! Clone nasm.git, cd into the directory then type:
Code: [Select]
$ git checkout nasm-2.15
$ git apply nasm-2.15-fixes.patch

And thanks for the words of encouragement Frank! Oh my, that was hard work!