macho gas support

[Alan Modra]

On Thu, May 28, 2026 at 12:01:07PM +0100, Iain Sandoe wrote:
> Hi Alan,
> 
> > On 26 May 2026, at 03:31, Alan Modra <amodra@gmail.com> wrote:
> > 
> > On Mon, May 25, 2026 at 10:46:11AM +0100, Iain Sandoe wrote:
> >> I will try to look at and test this - over the next week or two - is
> >> there a branch somewhere I can checkout?
> > 
> > Thanks!  I hadn't put them on a branch, but they are now on
> > binutils-gdb users/amodra/macho.
> 
> OK ..  so I worked on darwin17 which is the last OS version to support native 32b officially (albeit deprecated).
> 
> I built bfd, binutils and gas as 32b exes, using GCC-10.5 (unfortunately, the system clang does not build binutils on that platform).
> 
> $ ./gas/as-new --version
> GNU assembler (GNU Binutils) 2.46.50.20260526
> …
> This assembler was configured for a target of `i686-apple-darwin17’.
> 
> I also built current mainline 
> so the good news : basically repeat your results - with a couple of minor differences:
> -FAIL: i386 opcodes
> -FAIL: i386 opcodes (Intel disassembly)
> -FAIL: i386 opcodes (w/ suffix)
> -FAIL: i386 intel (AT&T disassembly)
> -FAIL: i386 intel
> -FAIL: i386 sub
> -FAIL: Check -madd-bnd-prefix
> -FAIL: x86-64 RTM insns
> -FAIL: x86-64 RTM insns (Intel disassembly)
> -FAIL: Check -madd-bnd-prefix (x86-64)
> 
> So that is progression - at least, in the context of the tests as framed.
> 
> ====
> 
> I then did a smoke-test with “hello-world.c” built -O0 -g
> 
> Now the not-so-good news is that we are not generating the correct relocations for some section differences:
> 
> e.g.
> system assembler											as-new
> RELOCATION RECORDS FOR [__text]:                                                RELOCATION RECORDS FOR [__text]:
> 00000027 GENERIC_RELOC_VANILLA _printf                                          00000027 GENERIC_RELOC_VANILLA _printf
> 00000021 GENERIC_RELOC_LOCAL_SECTDIFF lC1-0xb                                 | 00000021 GENERIC_RELOC_VANILLA lC1
> 00000017 GENERIC_RELOC_LOCAL_SECTDIFF lC0-0xb                                 | 00000017 GENERIC_RELOC_VANILLA lC0
> 00000007 GENERIC_RELOC_VANILLA __text                                           00000007 GENERIC_RELOC_VANILLA __text
> 
> …..
> 
> RELOCATION RECORDS FOR [__eh_frame]:                                            RELOCATION RECORDS FOR [__eh_frame]:
> 0000004c GENERIC_RELOC_LOCAL_SECTDIFF ___x86.get_pc_thunk.ax-0x100            | 0000004c GENERIC_RELOC_VANILLA __text
> 00000020 GENERIC_RELOC_LOCAL_SECTDIFF _main-0xd4                              | 00000020 GENERIC_RELOC_VANILLA __text

Yes, well, I don't see any support in gas to generate these SECTDIFF
relocs.  Does the hello-world run?

> despite this 
> $ dwarfdump --verify hello-gas.o 
> ----------------------------------------------------------------------
>  File: hello-gas.o (i386)
> ----------------------------------------------------------------------
> Verifying Compile Unit Header chain... ok
> Verifying .debug_info... ok
> Verifying .debug_frame... ok
> Verifying .debug_line… ok
> 
> —— which is somewhat confusing.
> 
> I then tried to do the same with an x86_64 asm (i686-darwin should be able to generate code for x86_64-darwin):
> 
> $ ./gas/as-new --64 hello.s -o hello-gas.o
> hello.s: Assembler messages:
> hello.s:113: Error: cannot represent relocation type BFD_RELOC_64_PCREL
> 
> Although one should note that, unlike i686 darwin,  x86_64-darwin dwarf mostly contains file offsets (not relocations) the linker is able to figure out the latter when parsing the dwarf sections.
> 
> =====
> 
> TBH .. unless there’s something blindingly obvious in my observations above, I wonder if it is worth putting in too much more effort into GAS (I spent ages around the 2.21ish era trying to get powerpc-darwin GAS to work, but that stuff bitrotted very quickly).

OK, then I won't spend any more time on x86-darwin gas.  If you or
Tristan want me to commit the patches I'll do so, but it not I'll just
drop them.

> I have some local patches that allow a working GDB for not too too old (14, I think), and getting the relocs right could be helpful to both that and binutils - which is the part I use most often on the older systems
> 
> thanks again for working on this,
> Iain
> 
> P.S. I will do an x86_64 build later for completeness sake.
> 

-- 
Alan Modra