macho gas support

[Iain Sandoe]

Hi Alan,

> On 29 May 2026, at 10:41, Alan Modra <amodra@gmail.com> wrote:
> 
> 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.

BFD understands them - I’d need to look out what I did for my powerpc experiments.

>  Does the hello-world run?

It does not link (using a GCC 10.5 - but built with an assembler supporting more modern idioms) - so that might not be 100% conclusive .. it does not link with mainline binutils either (different error).   it is possible that using generic relocs in those positions is just less efficient .. but .. IDK.

.. maybe i could try an older GCC too .. I’ll see over the w/e.

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

that makes most sense for now, there is clearly more work needed, and I would be very hard-pressed to justify it at this point.

.. although there is no new development of x86 on macOS - so whatever we (eventually) do - at least it will continue working on legacy systems once done.

>  If you or
> Tristan want me to commit the patches I'll do so, but it not I'll just
> drop them.

since they progress the testsuite - I’d say commit them - we evidently have other things to fix, but no point to repeat the work you already did.

thanks
Iain