From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 48373 invoked by alias); 15 Feb 2020 19:37:43 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 48364 invoked by uid 89); 15 Feb 2020 19:37:43 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-9.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.15.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 15 Feb 2020 19:37:42 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581795457; bh=R6CE2gaUoTC5wgHyfMHywFMMlfpRCxEViAROX3iKvLY=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date; b=cHrrJPZeLG8sxUXOGhzl4adStQieYXqbbaiKJBW2ZhlxxWwrfaJkxxkhF6cLIh+Z4 RnSBni0j/toOt3JiPwhl69T8ZGrR2xq4Kbvtj9k/ipx0Aq1T31TMiiE5mSYdCWwX0S Xv157LugqlMX/U16r+a/+FxKDdv43vqiNt7mXrqU= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from zbook-opensuse.wgnetz.xx ([95.115.92.68]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1Mzyya-1jQnB932vO-00x65w; Sat, 15 Feb 2020 20:37:37 +0100 From: Christian Eggers To: binutils@sourceware.org Cc: amodra@gmail.com Subject: [PATCH v3 0/2] Fix several mix up between octets and bytes in ELF program headers Date: Sat, 15 Feb 2020 19:37:00 -0000 Message-ID: <20564877.7Tol0G4XMo@zbook-opensuse.wgnetz.xx> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="us-ascii" X-IsSubscribed: yes X-SW-Source: 2020-02/txt/msg00377.txt.bz2 forgot the subject in my first mail.... On Wed, 18 Dec 2019 12:42:57 +1030, Alan Modra wrote: > Overall this is looking good, and I think your decision to make the > internal units for p_vaddr, p_paddr and sh_addr octets has worked out > well. Sorry for responding late. I do the binutils SDMA port in my leisure time. In the last two months I had to focus on my primary work and on my family. I hope that upstreaming of my SDMA work can be finished soon. > But it looks like you have missed a few places that need an octet per > byte factor... In order to ease review for you, I did only slight changes on the v2 patch and added the missing parts in a follow-up patch. > ...eg. elf.c search for filehdr_vaddr. Symbol values for > an address are in bytes, at least internally. added in the follow-up. > There's another one at > around line 7190 of elf.c where we have a comparison of an expression > involving p_vaddr and a section vma. also added in the follow-up. > That one raises the question of > what to do with alignment. Presumably, section->alignment_power stays > in bytes since it is most often used with section->vma. I added a comment on the struct member in the follow-up patch. > So that's > another thing that needs converting if used to align p_vaddr/p_paddr. In the follow-up, I also checked all users of section->alignment_power. > Also elfcode.h bfd_from_remote_memory uses p_vaddr without converting > to bytes. done in the follow-up. > Also search for phdr_lma in elf.c. done in the follow-up. > IS_CONTAINED_BY_LMA needs a fix too, changed in v3 of the first patch > and this in elf.c "map->p_paddr =3D matching_lma->lma" done in the follow-up > and the alignment a little later. unsure, maybe I didn't find > You also need to correct code in bfd_elf_final_link using sh_addr when > setting up DT_REL/DT_RELA. There's a comparison between sh_addr and > vma. done in the follow-up > The following in elf32-rx.c where octets per byte is always one (and > thus the file needs no change) is bogus, please remove, and the change > to elf64-ia64-vms.c too: removed in v3 of the first patch regards Christian