From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 93424 invoked by alias); 16 Feb 2020 08:22:29 -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 93416 invoked by uid 89); 16 Feb 2020 08:22:28 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-14.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=H*i:sk:2056487, H*f:sk:2056487, H*MI:sk:2056487, dear 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; Sun, 16 Feb 2020 08:22:27 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1581841343; bh=130damD5mtL8Sbsr4HBU2lZUrQmz41OdKd+qnt6ORJY=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=f/nhbpwf3BSRzVaZRsKYSL+Ao5teJoHnaiRpQCHVxyhtNdWt5e6i4BJjXaCmM+hzb 4og9DZ+1FuOJ6S5HliQPKLLkUq68fDV23ulSsy+GSVAhBEYAqUYDt21klD1EnzfHMB i7XVaJm3s3vqtpb6DnUf2hxLltVKNwn2tFLPsFjo= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from zbook-opensuse.wgnetz.xx ([77.7.44.64]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N4hvR-1jVKLw27Fv-011kpI; Sun, 16 Feb 2020 09:22:23 +0100 From: Christian Eggers To: binutils@sourceware.org Cc: amodra@gmail.com Subject: Re: [PATCH v3 0/2] Fix several mix up between octets and bytes in ELF program headers Date: Sun, 16 Feb 2020 08:22:00 -0000 Message-ID: <1780888.ZH1UJr1WQh@zbook-opensuse.wgnetz.xx> In-Reply-To: <20564877.7Tol0G4XMo@zbook-opensuse.wgnetz.xx> References: <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/msg00380.txt.bz2 Dear Alan, On Wed, 18 Dec 2019 12:42:57 +1030, Alan Modra wrote: > I'm also wondering about relocations, symbols and dynamic tags with > address values. I'm unsure whether I can answer this questions correctly because currently = "it simply works for me". But I will try... > Does r_offset specify bytes or octets in the ELF file? As far I can see, struct elf_internal_rela::r_offset is set from struct reloc_cache_entry::address [1]. from my gas/config/tc-sdma.c: arelent * sdma_cgen_tc_gen_reloc (asection *section, fixS *fixP) { arelent *reloc =3D gas_cgen_tc_gen_reloc(section, fixP); if (! (section->flags & SEC_ELF_OCTETS)) { reloc->address >>=3D OCTETS_PER_BYTE_POWER; } return reloc; } So it depends on whether SEC_ELF_OCTETS is set for the section where the relocation is installed. Particularly relocations offsets inside .debug_line are often not aligned to target bytes, see we need octets here. > If octets, then do we convert in elf_swap_reloca_in/out making > internal r_offset in bytes which should be most convenient since it is > often used with section vma? I think that no further conversion should be done here. > How about r_addend Usually in *bytes*, but for sections like .debug_str, *octets* are required. So it depends on whether SEC_ELF_OCTETS is set for the section of the symbo= l. > and st_value? debugging through gas showed that struct elf_internal_sym::st_value is set from struct bfd_symbol::value [2] which in turn is set from struct expressionS::X_add_number [3]. For sections like .text, all these values are in *bytes*. For sections which have SEC_ELF_OCTETS set (like .debug_info), there exists only the section symbols which have a value of 0. In absence of of "real" symbols inside the= se sections, I cannot say whether st_value can also be in octets. > Anyway, those can be left for a later patch if necessary. I hope this could clarify you questions. As I already said, from the point = of the SDMA, everything works fine as it is. regards Christian [1] bfd/elfcode.h:978 [2] bfd/elf.c:8139/8192 [3] gas/write.c:2311/2410