From: Joel Sherrill <joel.sherrill@gmail.com>
To: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
Cc: Kinsey Moore <kinsey.moore@oarcorp.com>,
"newlib@sourceware.org" <newlib@sourceware.org>
Subject: Re: AArch64 ILP32 strcmp bug
Date: Wed, 25 Nov 2020 08:11:05 -0600 [thread overview]
Message-ID: <CAF9ehCVHdXPAcxqYYwSgpXos5Ur5oz--=67u8u_yNkn6LaXM0w@mail.gmail.com> (raw)
In-Reply-To: <58625577-97a0-80eb-2d1f-626d5f89abf9@foss.arm.com>
Thanks Richard!
On Wed, Nov 25, 2020 at 5:29 AM Richard Earnshaw via Newlib <
newlib@sourceware.org> 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.
>
next prev parent reply other threads:[~2020-11-25 14:11 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-07-20 13:52 Kinsey Moore
2020-11-25 11:28 ` Richard Earnshaw
2020-11-25 14:11 ` Joel Sherrill [this message]
2020-11-26 18:41 ` Keith Packard
2020-11-26 19:02 ` Richard Earnshaw
2020-11-27 5:35 ` Keith Packard
2020-11-25 17:31 ` Kinsey Moore
2020-11-26 17:46 ` Richard Earnshaw
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAF9ehCVHdXPAcxqYYwSgpXos5Ur5oz--=67u8u_yNkn6LaXM0w@mail.gmail.com' \
--to=joel.sherrill@gmail.com \
--cc=Richard.Earnshaw@foss.arm.com \
--cc=kinsey.moore@oarcorp.com \
--cc=newlib@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).