Re: AArch64 ILP32 strcmp bug

Thanks Richard!

On Wed, Nov 25, 2020 at 5:29 AM Richard Earnshaw via Newlib <
[email protected]> wrote:

> On 20/07/2020 14:52, Kinsey Moore wrote:
> > Hi,
> > It appears that the hand-coded assembly in AArch64 strcmp does not
> sanitize the incoming address parameters in x0 and x1 when compiled for
> AArch64 ILP32. Based on my reading of the AArch64 Procedure Call
> Specification and GCC's output for similar function signatures, the callee
> is responsible for sanitization of the pointer addresses. I encountered
> this because I have a struct containing a pointer and length returned from
> another function that happens to get packed into a single register (x0) and
> GCC passes this unmodified into strcmp as the first argument.
> >
> > According to the aapcs64: "Any part of a register or a stack slot that
> is not used for an argument (padding bits) has unspecified content at the
> callee entry point."
> >
> > I suspect this is a problem for the majority of hand-written AArch64
> assembly in newlib.
> >
> > Please let me know if I missed something.
> >
> > Thanks,
> > Kinsey Moore
> >
>
> Apologies, somehow this message got marked as read although it never
> received a response.
>
> I don't think we've really added support for ILP32 to newlib.  This may
> just be one corner of a fairly large can of worms.
>
> The Arm/AArch64 optimized assembly routines are really just copies
> (provided that they've been kept up-to-date) of the code that Arm
> publishes as part of its Arm Optimized Routines package
> (https://github.com/ARM-software/optimized-routines); but even those do
> not have ILP32 support at this time.  The best place to address this is
> to raise an issue there.
>

I'm sure Kinsey will do that and look into providing a bare
metal test case that fails now.

In the meantime, would you think a patch to disable the optimized
method when ilp32 is appropriate for newlib? There is still the risk of
other methods having bugs. The alternative I see is to completely
PREFER_SIZE_OVER_SPEED for aarch64 and disable all of the
aarch64 assembly which seems worse.

Since this isn't RTEMS specific, I'd like to find a temporary workaround
that avoids the issue for all aarch64 targets.

Thanks.

--joel

R.
>