https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57438
--- Comment #24 from Iain Sandoe <iains at gcc dot gnu.org> --- (In reply to m...@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).
