public inbox for newlib@sourceware.org
 help / color / mirror / Atom feed
From: Richard Earnshaw <Richard.Earnshaw@foss.arm.com>
To: Kinsey Moore <kinsey.moore@oarcorp.com>,
	"newlib@sourceware.org" <newlib@sourceware.org>
Subject: Re: AArch64 ILP32 strcmp bug
Date: Wed, 25 Nov 2020 11:28:32 +0000	[thread overview]
Message-ID: <58625577-97a0-80eb-2d1f-626d5f89abf9@foss.arm.com> (raw)
In-Reply-To: <BN6PR19MB3201EAC562D6CA9D01A2BD5A907B0@BN6PR19MB3201.namprd19.prod.outlook.com>

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.

R.

  reply	other threads:[~2020-11-25 11:28 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 [this message]
2020-11-25 14:11   ` Joel Sherrill
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=58625577-97a0-80eb-2d1f-626d5f89abf9@foss.arm.com \
    --to=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).