public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@gmx.de>
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	[thread overview]
Message-ID: <1780888.ZH1UJr1WQh@zbook-opensuse.wgnetz.xx> (raw)
In-Reply-To: <20564877.7Tol0G4XMo@zbook-opensuse.wgnetz.xx>

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 = gas_cgen_tc_gen_reloc(section, fixP);
  if (! (section->flags & SEC_ELF_OCTETS))
    {
      reloc->address >>= 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 symbol.

> 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 these
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



  reply	other threads:[~2020-02-16  8:22 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-15 19:37 Christian Eggers
2020-02-16  8:22 ` Christian Eggers [this message]
2020-02-16 19:37   ` Christian Eggers
2020-02-20  1:30     ` Alan Modra
2020-02-22 16:32       ` Christian Eggers
2020-02-22 21:08       ` Christian Eggers
2020-02-23  9:07       ` Christian Eggers
2020-02-27  8:35         ` Alan Modra
2020-03-07 21:05           ` Christian Eggers
2020-02-23 18:35       ` Christian Eggers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1780888.ZH1UJr1WQh@zbook-opensuse.wgnetz.xx \
    --to=ceggers@gmx.de \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).