Changes between Initial Version and Version 1 of Ticket #70859, comment 54


Ignore:
Timestamp:
Oct 2, 2024, 5:46:52 PM (9 days ago)
Author:
markmentovai (Mark Mentovai)
Comment:

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #70859, comment 54

    initial v1  
    77Details:
    88
    9 There does appear to be a bug in Apple’s new linker (ld-new or ld-prime) when targeting x86_64, producing a Mach-O dynamic library (`clang -dynamiclib`), and using the flat namespace option (`-flat_namespace`). I observed this as a variety of crashes in `make check`. I investigated t-bdiv raising SIGILL in particular:
     9There does appear to be a bug in Apple’s new linker (ld-new or ld-prime) when targeting x86_64, producing a Mach-O dynamic library (`clang -dynamiclib`), and using the flat namespace option (`-flat_namespace`). I observed this as a variety of crashes in `make check`. I investigated t-bdiv raising `SIGILL` in particular:
    1010
    1111{{{
    … …  
    3131}}}
    3232
    33 With the fault address at 0x1000de806 falling partway through the instruction at 0x1000de803, this certainly would be a bad instruction. This code was assembled from https://gmplib.org/repo/gmp-6.3/file/62abbaeaab13/mpn/x86_64/core2/aors_n.asm, at the bottom of the file has `__gmpn_sub_nc` jumping to within (but not the beginning of) `__gmpn_sub_n`. Duplicating that structure in a reduced testcase:
     33With the fault address at `0x1000de806` falling partway through the instruction at `0x1000de803`, this certainly would be a bad instruction. This code was assembled from https://gmplib.org/repo/gmp-6.3/file/62abbaeaab13/mpn/x86_64/core2/aors_n.asm, at the bottom of the file has `__gmpn_sub_nc` jumping to within (but not the beginning of) `__gmpn_sub_n`. Duplicating that structure in a reduced testcase:
    3434
    3535{{{
    … …  
    9292}}}
    9393
    94 The jump at 0xf95 is bad: 0xf9f is a bad jump target. As before, that address lies within another instruction (in this case, the last byte of the instruction at 0xf9a). In fact, that’s the very last byte of the section:
     94The jump at `0xf95` is bad: `0xf9f` is a bad jump target. As before, that address lies within another instruction (in this case, the last byte of the instruction at `0xf9a`). In fact, that’s the very last byte of the section:
    9595
    9696{{{
    … …  
    111111}}}
    112112
    113 The jump at 0xf95 should target 0xf85, or _G + 0x5. For some reason, the linker created a stub for this jump (which itself shouldn’t be necessary) and then, instead of arranging for the stub to resolve and jump to _G + 0x5, jumped to offset 0x5 within the stub.
     113The jump at `0xf95` should target `0xf85`, or `_G + 0x5`. For some reason, the linker created a stub for this jump (which itself shouldn’t be necessary) and then, instead of arranging for the stub to resolve and jump to `_G + 0x5`, jumped to offset `0x5` within the stub.
    114114
    115115This is a clear bug in the linker, and I’ll report it to Apple, but don’t know that anyone could expect much traction.
    116116
    117 That doesn’t need to be the end of the story. There’s another concern here: this bug only occurs with -flat_namespace. gmp shouldn’t need -flat_namespace, and in fact it’s undesirable to enable it. It’s coming into this build from configure, via aclocal.m4, having been included from libtool.m4. In libtool-2.4.6, which gmp-6.3.0 is using, that’s https://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4?h=v2.4.6#n1070. In particular, it intends to enable -flat_namespace only on very early Mac OS X versions (pre-10.4, in the PowerPC-only era). But the case that we’d like to hit, assuming `MACOSX_DEPLOYMENT_TARGET` is unset (as it normally would be), doesn’t match `$host` on a modern macOS system, because the Darwin version has marched past 20, while the pattern only contemplates versions up to 19.
     117That doesn’t need to be the end of the story. There’s another concern here: this bug only occurs with `-flat_namespace`. gmp shouldn’t need `-flat_namespace`, and in fact it’s undesirable to enable it. It’s coming into this build from configure, via aclocal.m4, having been included from libtool.m4. In libtool-2.4.6, which gmp-6.3.0 is using, that’s https://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4?h=v2.4.6#n1070. In particular, it intends to enable `-flat_namespace` only on very early Mac OS X versions (pre-10.4, in the PowerPC-only era). But the case that we’d like to hit, assuming `MACOSX_DEPLOYMENT_TARGET` is unset (as it normally would be), doesn’t match `$host` on a modern macOS system, because the Darwin version has marched past 20, while the pattern only contemplates versions up to 19.
    118118
    119 https://git.savannah.gnu.org/cgit/libtool.git/commit/m4/libtool.m4?id=9e8c882517082fe5755f2524d23efb02f1522490, in libtool-2.4.7, modernizes this check in libtool, and with that in use, does not enable -flat_namespace in this situation. Upgrading libtool in gmp to that version will fix this problem. I ran `autoreconf --install` with autoconf-2.69, automake-1.15, and libtool-2.4.7, and observed a clean `make check` on macOS 14.7 x86_64 (nehalem-apple-darwin23.6.0)/Xcode 15.4 and macOS 15.0 x86_64 (nehalem-apple-darwin24.0.0)/Xcode 16.0. In both cases, the linker is ld-new/ld-prime (no `-ld_classic`).
     119https://git.savannah.gnu.org/cgit/libtool.git/commit/m4/libtool.m4?id=9e8c882517082fe5755f2524d23efb02f1522490, in libtool-2.4.7, modernizes this check in libtool, and with that in use, does not enable `-flat_namespace` in this situation. Upgrading libtool in gmp to that version will fix this problem. I ran `autoreconf --install` with autoconf-2.69, automake-1.15, and libtool-2.4.7, and observed a clean `make check` on macOS 14.7 x86_64 (nehalem-apple-darwin23.6.0)/Xcode 15.4 and macOS 15.0 x86_64 (nehalem-apple-darwin24.0.0)/Xcode 16.0. In both cases, the linker is ld-new/ld-prime (no `-ld_classic`).