This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: mfentry and Darwin.
- From: Uros Bizjak <ubizjak at gmail dot com>
- To: Iain Sandoe <iain at sandoe dot co dot uk>
- Cc: GCC Development <gcc at gcc dot gnu dot org>
- Date: Tue, 21 May 2019 20:36:54 +0200
- Subject: Re: mfentry and Darwin.
- References: <975BF895-99C7-4249-A1CA-B4B69690E453@sandoe.co.uk>
On Tue, May 21, 2019 at 6:15 PM Iain Sandoe <iain@sandoe.co.uk> wrote:
>
> Hi Uros,
>
> It seems to me that (even if it was working “properly”, which it isn't) ‘-mfentry’ would break ABI on Darwin for both 32 and 64b - which require 16byte stack alignment at call sites.
>
> For Darwin, the dynamic loader enforces the requirement when it can and will abort a program that tries to make a DSO linkage with the stack in an incorrect alignment. We previously had a bug against profiling caused by exactly this issue (but when the mcount call was in the post-prologue position).
>
> Actually, I’m not sure why it’s not an issue for other 64b platforms that use the psABI (AFAIR, it’s only the 32b case that’s Darwin-specific).
The __fentry__ in glibc is written as a wrapper around the call to
__mcount_internal, and is written in such a way that it compensates
stack misalignment in a call to __mcount_internal. __fentry__ survives
stack misalignment, since no xmm regs are saved to the stack in the
function.
> Anyway, my current plan is to disable mfentry (for Darwin) - the alternative might be some kind of “almost at the start of the function, but needing some stack alignment change”,
>
> I’m interested in if you know of any compelling use-cases that would make it worth finding some work-around instead of disabling.
Unfortunately, not from the top of my head...
Uros.