From patchwork Fri Jun 24 08:25:52 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Kito Cheng X-Patchwork-Id: 55370 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 B5A12384D1AC for ; Fri, 24 Jun 2022 08:26:21 +0000 (GMT) X-Original-To: libc-alpha@sourceware.org Delivered-To: libc-alpha@sourceware.org Received: from mail-pl1-x62b.google.com (mail-pl1-x62b.google.com [IPv6:2607:f8b0:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id 1AEF7385AE44 for ; Fri, 24 Jun 2022 08:26:09 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1AEF7385AE44 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-x62b.google.com with SMTP id o18so1519328plg.2 for ; Fri, 24 Jun 2022 01:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sifive.com; s=google; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=HjXgvBrw7E8khZRjebwFFYOARquzfSq9p77XOnPznXU=; b=Sn01vtMh5XSwbne4LpVu3bNpkFKd+ZK5f5HNA/sJ2BgeJVXBXtQ3ynNA0IL2OqTqmo PD3bG1Cf+RWRqJeuWpryAhqG82cYNXrLQzosXQdmcUoRUuqWO3WfwYItS2XSPaLb96df WEhcktt6fZE6Vj/jrlyk7tv8K4h6HxHJUdP5XbdHb17lTe1zojgbkuyDsIEEVAVTjTo4 C/AvNcmP0Qjib0RGTgsljJmixoWBGwhJbmZ9zgDRexFJu79E6bzMF336BJABRcibzYHd l3hc+o41XJwNSDwKagb4E1kEOotMpEBdw65Vmla2YNlSeZnp603lCP3QUT/z7ILAqf52 YK5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=HjXgvBrw7E8khZRjebwFFYOARquzfSq9p77XOnPznXU=; b=x4gKC+KroTvrmSAU/mNykE6msY+nk0iAXSz0ZxOI+e/u3qc3QV+KMSDyRnmV37oYk4 3DyhqQ7z7rCGlhCfbJFff7bW6hqIwyWhoXQNNRp1PDKXZGHP1xGXYgF8Utgq6VYP2f7/ YLH/p1N/y1Gqcu2fB3HbTLxe8ArZaPjlQMyGTtQWCYiMh1AQ4BPbM2h5r9XvNbsDDxl4 kEihMKOf1QfwR2c4R39vN+MhOuKC9BYyEF3mX86L7FbhmE0Se7ryI911l11dmwJkfVjZ V2O9yOQY+y8YDMfW/uzjag7IReQn2/EOcmzwDP2p6Q2NjDTLHtZz2Ila0IMrsG/19TWr uXVg== X-Gm-Message-State: AJIora9TzBiIXzThoOGpLzbq7vyAkN7G4udQLw9e1keZZ3ZAT3AknTGs HOau0x7QSOZp7stfDMF4cofY6iZc6vQCVA== X-Google-Smtp-Source: AGRyM1tf8Or413aX3VnC2YcMYQSxK9tSE+eWMhFeUImEq3n4Se7FeTjZBXx+QX4017JzXKIJ7Wv6WA== X-Received: by 2002:a17:902:7792:b0:16a:463e:296c with SMTP id o18-20020a170902779200b0016a463e296cmr13287108pll.138.1656059167834; Fri, 24 Jun 2022 01:26:07 -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 k26-20020aa7821a000000b0052517150777sm1049054pfi.41.2022.06.24.01.26.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 24 Jun 2022 01:26:07 -0700 (PDT) From: Kito Cheng To: libc-alpha@sourceware.org, kito.cheng@gmail.com, palmer@dabbelt.com, darius@bluespec.com, adhemerval.zanella@linaro.org Subject: [PATCH] riscv: Use memcpy to handle unaligned access when fixing R_RISCV_RELATIVE Date: Fri, 24 Jun 2022 16:25:52 +0800 Message-Id: <20220624082552.50478-1-kito.cheng@sifive.com> X-Mailer: git-send-email 2.34.0 MIME-Version: 1.0 X-Spam-Status: No, score=-13.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, 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: , Cc: Kito Cheng Errors-To: libc-alpha-bounces+patchwork=sourceware.org@sourceware.org Sender: "Libc-alpha" Although RISC-V Linux will enable the unaligned memory access handler by default, that is quite expensive in general, using memcpy will be much cheaper - just break down that into several load/store byte instructions. 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 Acked-by: Palmer Dabbelt Reviewed-by: Adhemerval Zanella --- sysdeps/riscv/dl-machine.h | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/sysdeps/riscv/dl-machine.h b/sysdeps/riscv/dl-machine.h index 4bb858adaa..a880567c3c 100644 --- a/sysdeps/riscv/dl-machine.h +++ b/sysdeps/riscv/dl-machine.h @@ -157,7 +157,10 @@ __attribute__ ((always_inline)) elf_machine_rela_relative (ElfW(Addr) l_addr, const ElfW(Rela) *reloc, void *const reloc_addr) { - *(ElfW(Addr) *) reloc_addr = l_addr + reloc->r_addend; + /* R_RISCV_RELATIVE might located in debug info section which might not + aligned to XLEN bytes. Also support relocations on unaligned offsets. */ + ElfW(Addr) value = l_addr + relic->r_addend; + memcpy (reloc_addr, &value, sizeof value); } /* Perform a relocation described by R_INFO at the location pointed to