From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 105116 invoked by alias); 22 Feb 2020 21:08:47 -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 105104 invoked by uid 89); 22 Feb 2020 21:08:46 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-4.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.1 spammy=ups, Four, calculations X-HELO: mout.gmx.net Received: from mout.gmx.net (HELO mout.gmx.net) (212.227.17.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 22 Feb 2020 21:08:45 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1582405722; bh=CjbLgxl55MxAhvzjGH9Flvgem/qiX7oqw4LAb10PfSA=; h=X-UI-Sender-Class:From:To:Cc:Subject:Date:In-Reply-To:References; b=HuPgPawjGCNY1mJInipc0w8NeotFYE1c/U8UxJQ5Kq6tsgbGdtembbtqfx4/lYa4Z zpWdsdW0QzZX0SoPDrXeTDh/HA/Rg4I4XU4eu/Cx4SJ7VCTYZySdzSN1FZeu6APB1H OJvw7Q9egRdlTwL8A6yUxBAjb+MWR2zQQMRTvjsE= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from zbook-opensuse.wgnetz.xx ([95.117.45.69]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MUXtY-1iwupl3XKS-00QVXG; Sat, 22 Feb 2020 22:08:41 +0100 From: Christian Eggers To: Alan Modra Cc: binutils@sourceware.org Subject: Re: [PATCH v3 0/2] Fix several mix up between octets and bytes in ELF program headers Date: Sat, 22 Feb 2020 21:08:00 -0000 Message-ID: <6139167.rgW7P1J3pl@zbook-opensuse.wgnetz.xx> In-Reply-To: <20200220012952.GW5570@bubble.grove.modra.org> References: <20564877.7Tol0G4XMo@zbook-opensuse.wgnetz.xx> <5653117.1aehKcCLEe@zbook-opensuse.wgnetz.xx> <20200220012952.GW5570@bubble.grove.modra.org> 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/msg00515.txt.bz2 > > How about r_addend > > Usually in *bytes*, but for sections like .debug_str, *octets* are requir= ed. > So it depends on whether SEC_ELF_OCTETS is set for the section of the > symbol. In order to generate a relocation in GAS, at first a fixup is created: gas_cgen_finish_insn() +--gas_cgen_record_fixup_exp() +--fix_new_exp() +--fix_new_internal() <-- allocation of fixS object In case the relocation is PC relative, MD_PCREL_FROM_SECTION(fix, section) = is called later: write_object_file() +--bfd_map_over_sections (..., fix_segment, ...); +--fix_segment() +--fixup_segment() +--md_pcrel_from_section() ... return (fixP->fx_where + fixP->fx_frag->fr_address) >> OCTETS_P= ER_BYTE_POWER While fixP->fx_where is in octets, the result has to be converted to bytes.= It is used within fixup_segment for calculations with other byte values: ... add_number =3D fixP->fx_offset; ... add_number +=3D S_GET_VALUE (fixP->fx_addsy); fixP->fx_offset =3D add_number; if (fixP->fx_pcrel) add_number -=3D MD_PCREL_FROM_SECTION (fixP, this_segment); ... All fix ups, which could not be fixed up, are converted to relocations in gas_cgen_tc_gen_reloc(). Here fixS::fx_offset/fx_addnumber is copied to arelent::addend: write_object_file() +--bfd_map_over_sections() +--write_relocs() +--tc_gen_reloc() +--gas_cgen_tc_gen_reloc() ... reloc->addend =3D fixP->fx_addnumber; ... All users of arelent::addend clearly deal with bytes, not octets. Conversion between arelent::addend and elf_internal_rela::r_addend happens = in elf_slurp_reloc_table_from_section() and elf_write_relocs(). elf_internal_rela::r_addend has the following users: - _bfd_elf_rela_local_sym(): + rel->r_addend =3D _bfd_merged_section_offset(.., sym->st_value + rel->r= _addend) * Have a look at st_value later * _bfd_merged_section_offset() deals with octets, not bytes + Two additional conversion required. - bfd_elf_perform_complex_relocation() + decode_complex_addend(..., rel->r_addend) * r_addend has special meaning for complex relocations and must not be altered in this case - elf_swap_reloc(a)_in/out(): No change - elf_write_relocs(): Change: Convert arelent::address to octets (depending= on SEC_ELF_OCTETS) - elf_gc_smash_unused_vtentry_relocs(): No change - elf_link_input_bfd: Four additional conversion required - elf_reloc_link_order(): Copy from bfd_link_order_reloc::addend. That shou= ld be kept in bytes. - elf_slurp_reloc_table_from_section(): Convert from octets to bytes (depen= ding on SEC_ELF_OCTETS) All other users are in readelf, which expects octets in all cases. Conclusion: "Changing" Elf_Internal_Rela::r_addend to octets looks straightforward as for r_offset. At next, I will have a look for st_value and debug info. Regards Christian