https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100152
--- Comment #45 from Iain Sandoe <iains at gcc dot gnu.org> ---
the i386 backend code already sets :
TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS to true unconditionally.
So, it seems that it might be necessary to find some way to adjust
CALL_INSN_FUNCTION_USAGE.
because...
===
Simply setting an override to PIC or (PIC && !PIE) results
* in a large number of testsuite regressions
* and doesn't seem to match the behaviour of the system compiler (a.k.a.
clang).
Noting that x86_64 Darwin is _always_ PIC.
clang does not discriminate between PIC and PIE code in the compiler, the
driver maps both to -mrelocation-model pic 2 (and that's the default anyway).
The static linker does act upon PIE - to the extent that it defaults to PIE for
executables, although that can be overridden with -Wl,-no_pie (which we use to
allow PCH to work in GCC).
====
it seems [from looking at clang's output ] that we want this to be the
behaviour in a dylib:
.. foo () { ... }
.. bar () { ... foo () ... }
When we have a sufficient optimisation level to allow inlining - then we want
foo to be inlined into bar (for the default case of PIC).
When the static linker acts - it will make both foo and bar available publicly
- and an external caller to those will use lazy symbol resolution.
If foo is not suitable for inlining then the call to it from bar() will be
indirected through the lazy symbol binder if the dylib is built with
-flat_namespace, (which was the case in the gambit scenario here, I think).
====
I suppose the argument is that if we call a specific implementation of bar(),
we expect the complete implementation (including *that* library's version of
foo() and not some mixture of that and some interposed one) and therefore it's
logical to allow the inlining.
If one wants to guarantee that foo can be interposed [including in any case
like bar()], then either one needs to build -fno-inline or mark foo as
__attribute__((__noinline__)) [or weak]
TBH this seems quite fragile to me - but OTOH people interposing libraries
better know what they are doing - going to ask the Apple ABI folks to confirm
my hypothesis.
=====
Anyway .. we can't fix the problem quickly by applying PIC && !PIE - because
that is too big a hammer for Darwin.
I think what will be needed is to append r10 and r11 to the Call clobbered
registers .. but I've not figured out exactly where to do this yet. [ setting
CALL_INSN_FUNCTION_USAGE somewhere, or so ]
It doesn't seem that i386 has this problem (but needs double-checking).
