From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) by sourceware.org (Postfix) with ESMTPS id 63D223857811 for ; Wed, 25 Nov 2020 14:11:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 63D223857811 Received: by mail-lf1-x12a.google.com with SMTP id t6so3267511lfl.13 for ; Wed, 25 Nov 2020 06:11:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=KX1JRmVwkrV/0y3bzrafmowcVhavXC4VTe1N92IX0gc=; b=oieoPBHh2u2PsW3dX6XKgJy8sG4ZiDzQ8quJJuT9X4W9ztCFMNDz3QcDpcHOAfbCA/ cIoO5VlfCafoBLnBR4sAtcBP3dVm4nMJzmQtBKig3Cno07H5+vhC/PdQtz8McsmZit+I CAR7EeQbl4l0wESOCFJdXBZ8eznQJwLpYzSGSeZmsGmEpsCfiq9eFRa7h0BFDgRhoefl Gc+iyAEiToHm5oft13eW9KK3ySZB6uPGFVdXuDVLmYXPmY6k7JDF/OLUdA5tiY3q8bYk qe8UcV67gugL6GouZ079dUc/TRoyDI9mwr/tbYKOV8XI8Xp7qZj0TtkbyQIbJ7x9u7w4 R3wA== X-Gm-Message-State: AOAM533X2ZdtQIlYXDEI4QOBcZ9q+MvX8cHVcAcvflBXyuRE56UiSsLb DvjSXTH5MnODM3kNgRq57R1qIXuGFC3ljav7WlCpQjsNpnM= X-Google-Smtp-Source: ABdhPJyOP+PmRld+S191LvUZqmeGoZOhfmR1iTVFIvdK6sSIiekrmt7P0gOOeOIUmNrdsHzN+ObOjWLRu9vp620yxLk= X-Received: by 2002:a05:6512:501:: with SMTP id o1mr1456833lfb.96.1606313477085; Wed, 25 Nov 2020 06:11:17 -0800 (PST) MIME-Version: 1.0 References: <58625577-97a0-80eb-2d1f-626d5f89abf9@foss.arm.com> In-Reply-To: <58625577-97a0-80eb-2d1f-626d5f89abf9@foss.arm.com> From: Joel Sherrill Date: Wed, 25 Nov 2020 08:11:05 -0600 Message-ID: Subject: Re: AArch64 ILP32 strcmp bug To: Richard Earnshaw Cc: Kinsey Moore , "newlib@sourceware.org" X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 14:11:20 -0000 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. >