From patchwork Thu Jun 23 15:47:03 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kito Cheng X-Patchwork-Id: 55053 Return-Path: X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F042B38515F5 for ; Thu, 23 Jun 2022 15:48:07 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pl1-x62d.google.com (mail-pl1-x62d.google.com [IPv6:2607:f8b0:4864:20::62d]) by sourceware.org (Postfix) with ESMTPS id 8A026384A876 for ; Thu, 23 Jun 2022 15:47:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8A026384A876 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=sifive.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=sifive.com Received: by mail-pl1-x62d.google.com with SMTP id a17so16537285pls.6 for ; Thu, 23 Jun 2022 08:47:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=CEDYpB7E4eSjmpIZaRiWusizt3/Q8pvMs3CvPB4ALCk=; b=VZTyEzmUzfRkCb4E0pAXE/O9ZIAuhtsQHv8ceQg4JCNTdsuBSxp1uEPepKjTXLq5S0 SZ12wN48TtWM9xpego6ywyNs1O5g3Ao2acHtQ5zRc3bleHRsf3jPBk7D3vBUfNLoPUxV eeYyJyhBcGF6pX6VRMkA67I+hTbYJ/1gcqbWINnXzPZi0da64QrB2sTrcVTdRz2mwZDU omKnbmT3Vu0egyxvLtA/wYajq+bYq73mBP9ZJ3mfcpJ4QS+7W6kH5AdoUoqY9mZ/bVYT j5Vu9P5Indrh30CK5ol55ULFyfqel9tomQBJWHw6vkAG1hQnTqTglYWPXLRvdflVxvPw Btog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=CEDYpB7E4eSjmpIZaRiWusizt3/Q8pvMs3CvPB4ALCk=; b=NBDLurRHDLvX0ae6dGZpjvtRZFYMnQR6i3NVDjVDk3JSdTP7jUocpsgSQG3Ah3Tkoo pAfqfp2gh3QdA+VIY+vhkIXOGxAkm/7979Z0l0RGru248hoEoq47kv1I9KV6sZLBQTFX KAyQjXiizHJVzFdflLbsb47gZVbm6FXmOVYaQbTrPN7mmQOQ/mWQWkFK7ChJeH7Dg6AS 7R990xP8JVlTeWLXEBiiJAo4TwzM+g8xzW9Hyrj7Mpa5MGL//oOEaBGWpXpFOxYPu0gp P0wZfGb6aYw03BAWWo9OaD9GBMSCd+PNmM6/MwhydqZUcLRcWrJzwzHqs4RqT+YN3zid 3skw== X-Gm-Message-State: AJIora8GN3TFco2niBA3FIquMnWVF//I+8baKu6tYGtEFrhbEoHK0QuK AG44oTEVi1XHsMA+8Ny+SgfsQ4Z1I9rpMA== X-Google-Smtp-Source: AGRyM1tBuw+nCeI6FoRs0m71STZDj1dZnfGy22Lf9aCvI4irsoxn6uiWb8+POsminXd6XSn45sFl9Q== X-Received: by 2002:a17:902:bf49:b0:16a:87a:349e with SMTP id u9-20020a170902bf4900b0016a087a349emr32072991pls.86.1655999235290; Thu, 23 Jun 2022 08:47:15 -0700 (PDT) Received: from hsinchu02.internal.sifive.com (59-124-168-89.hinet-ip.hinet.net. [59.124.168.89]) by smtp.gmail.com with ESMTPSA id 20-20020a621614000000b0052551c1a413sm2453126pfw.204.2022.06.23.08.47.13 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 23 Jun 2022 08:47:14 -0700 (PDT) From: Kito Cheng To: libc-alpha@sourceware.org, kito.cheng@gmail.com, palmer@dabbelt.com, darius@bluespec.com Subject: [PATCH 0/2] riscv: Prevent potential unaligned memory access during dynamic relocation Date: Thu, 23 Jun 2022 23:47:03 +0800 Message-Id: <20220623154705.14416-1-kito.cheng@sifive.com> X-Mailer: git-send-email 2.34.0 MIME-Version: 1.0 X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, KAM_SHORT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" We found a potential unaligned store during resolving the dynamic relocation stage - R_RISCV_RELATIVE might be located in a non-XLEN aligned location, because that is used in debug sections. However this issue wasn't discovered before since RISC-V Linux is enabled the unaligned memory access handler by default, so this isn't a big issue so far, but as we know the unaligned memory access handler is very expensive, and that might impact the program start up time, so letting compiler emit sequence of load/store would be much better solution. NOTE: ARM and MIPS has similar issue: ARM: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51456 MIPS: https://gcc.gnu.org/legacy-ml/gcc-help/2005-07/msg00325.html