mfentry and Darwin.

mfentry and Darwin.

[Iain Sandoe]

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).

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.

thanks
Iain

Re: mfentry and Darwin.

[Uros Bizjak]

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.

Re: mfentry and Darwin.

[Iain Sandoe]

Hi Uros,

> On 21 May 2019, at 19:36, Uros Bizjak <ubizjak@gmail.com> wrote:
> 
> On Tue, May 21, 2019 at 6:15 PM Iain Sandoe <iain@sandoe.co.uk> wrote:
>> 

>> 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.

Well, we can’t change Darwin’s libc to do something similar (and anyway the dynamic loader would also need to know that this was a special as well to avoid aborting the exe).

... however we could do a dodge where some shim code was inserted into any TU that used  mfentry to redirect the call to an ABI-compliant launchpad… etc. etc.

It seems we can’t instrument “exactly at the entry” .. only “pretty close to it”.

>> 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…

Well, I can’t either, so for now I’m going to make a patch to disable it (since it’s not fully working in any case) .. if anyone screams that there’s a major reduction in functionality - we can investigate some scheme as mentioned above.

thanks
Iain