macho gas support

[Iain Sandoe]

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

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).

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.