Fix debuginfo for machO

[bjorn3]

This only fixes it when using object::write as backend, and not when using faerie.

There were two problems:

• object::write doesn't replace .debug_info with __debug_info, unlike faerie
• machO requires section relative relocations, and not symbol relative
  relocations. When using symbol relative relocations, the linker
  interprets the relocations as section relative. Thus writing the wrong
  values to the debug sections.

Fixes #303

cc @philipc

TODO

• Verify that using section relative relocations doesn't break debuginfo on Linux

[philipc]

Both of these might be candidates for including in object::write somehow. I'll have to take some time to understand the relocations though. Fixing it here first is fine of course.

[philipc]

For the section names, ideally object::write::StandardSection would contain all the DWARF sections too, and then you could use Object::section_id to create the DWARF sections, but the problem is there's nothing to define the relationship between object::write::StandardSection and gimli::SectionId. I think the change you have here is the easiest way for now.

For the relocations, it looks like LLVM always uses section relative relocations where possible (see ELFObjectWriter::shouldRelocateWithSymbol and MachObjectWriter::doesSymbolRequireExternRelocation). For object::write, I'm currently only using section-relative when required, so I probably should reverse that logic to be always section-relative unless required otherwise, and then you wouldn't need any fix here.

One thing I need to learn more about is that, for debuginfo, I think references to global data shouldn't be section-relative, but references to global functions should be section-relative, but I don't know where LLVM makes this decision, so I'm not sure if I have this completely right yet.

[bjorn3]

For object::write, I'm currently only using section-relative when required, so I probably should reverse that logic to be always section-relative unless required otherwise, and then you wouldn't need any fix here.

I would prefer to keep it that way. Symbol relative relocations are much more useful when having to look at the output object files than section relative relocations. For the later, you would have to search for which symbol is declared at the given offset, while for the former you can see the symbol name immediately.

It may be useful to have a function from symbol relative -> section relative relocation.

[philipc]

One thing I need to learn more about is that, for debuginfo, I think references to global data shouldn't be section-relative, but references to global functions should be section-relative

So I think the way this works in LLVM is that the function addresses in debuginfo are references to temporary labels, not the function symbol, and so they are converted to section relative relocations. object::write doesn't know about labels (at least, it doesn't know about labels that don't appear as symbols), so this isn't something it can handle currently.

It may be useful to have a function from symbol relative -> section relative relocation.

gimli-rs/object#133

[bjorn3]

Adapted for gimli-rs/object#133 and confirmed that that Linux debuginfo still works.