[Bug bootstrap/57438] bootstrap fails on x86_64 darwin in stage2 linking cc1

["iains at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438

--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to mrs@gcc.gnu.org from comment #23)
> On the platform, external symbols are defined to be 1 or more bytes.  0 is
> not one or more.  Once that is fixed, then the problem goes away.  If you
> want to have Apple update their abi for future systems to include zero byte
> objects, you will have to ask them to change their abi.

Well, I'm very aware of the constraint that has been applied our output to date
(having implemented some of the "fixes" for it).  However, it was my
understanding that the constraint was one of the tools; I.E. ld64's ability to
determine an unambiguous 'atom'.  I can't find anything in the written ABI or
assembler documentation that makes such a statement (although we accept that
"what the other tools do" is the effective ABI).

It appears that (recently) ld64 [and the assembler] have been modified to
support symbol aliases.  Thus the constraint you mention has been
amended/modified; newer versions of ld64 are not complaining about the 0-sized
functions (or co-incident symbols), only the 0-sized FDE.

It would be quite a useful step forward to support symbol aliases - since the
absence has been a source of difficulty for us - but let's not get side-tracked
from the actual problem.

----

1. FWIW There is code in i386.c [12410 - 12438] that is supposed to ensure that
functions on Darwin contain at least a NOP.  However, it clearly isn't working
in these cases.

----

2. The issue of whether Darwin can have 0-sized functions is actually a
separate one from whether GCC should emit FDEs for 0-sized functions (since
other platforms can clearly support them).