From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by sourceware.org (Postfix) with ESMTP id 240453861972 for ; Wed, 25 Nov 2020 11:28:57 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 240453861972 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id A26EC106F; Wed, 25 Nov 2020 03:28:56 -0800 (PST) Received: from [192.168.1.19] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 2C3F13F70D; Wed, 25 Nov 2020 03:28:56 -0800 (PST) Subject: Re: AArch64 ILP32 strcmp bug To: Kinsey Moore , "newlib@sourceware.org" References: From: Richard Earnshaw Message-ID: <58625577-97a0-80eb-2d1f-626d5f89abf9@foss.arm.com> Date: Wed, 25 Nov 2020 11:28:32 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3492.7 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: newlib@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Newlib mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Nov 2020 11:28:58 -0000 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.