public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Christian Eggers <ceggers@gmx.de>
To: Alan Modra <amodra@gmail.com>
Cc: binutils@sourceware.org
Subject: Re: [PATCH v3 0/2] Fix several mix up between octets and bytes in ELF program headers
Date: Sun, 23 Feb 2020 09:07:00 -0000	[thread overview]
Message-ID: <13081552.YODp3BJPb1@zbook-opensuse.wgnetz.xx> (raw)
In-Reply-To: <20200220012952.GW5570@bubble.grove.modra.org>

> > 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.
> ...
> [2] bfd/elf.c:8139/8192
> [3] gas/write.c:2311/2410

elf_internal_sym::st_value has the following users:
- _bfd_elf_rel_local_sym():
  + Parameter "added" is sometimes octets, sometimes bytes.
    * Only used for architectures where this doesn't matter
  + _bfd_merged_section_offset() deals with octets, not bytes
  + result should be kept in bytes
- _bfd_elf_rela_local_sym(): Needs one conversion
- adjust_eh_frame_local_symbols():
  + delta = offset_adjust (sym->st_value, sec)
    * offset_adjust() uses octets/bytes inconsistently, needs fixes
      - eh_cie_fde::offset should be kept in octets
    * offset_adjust() should better return bytes
- asymbol_from_plugin_symbol(): No change?
- bfd_elf_final_link(): Needs 4 conversions.
- bfd_elf_print_symbol(): Only printf, may be kept as it is
- elf_slurp_symbol_table(): Copies to bfd_symbol::value, needs conversion
- elf_swap_symbol_in/out(): No change
- elf_common_parse():
  ...
  align = parse_align (is_local);
  ...
  S_SET_ALIGN (symbolP, align);
  +-- st_value = align ???   <--- why? But needs conversion
- elf_link_add_object_symbols(): More complicated!
  + bfd_vma value = isym->st_value  <-- octets
    ...
    value = isym->st_size;          <-- octets
    ...
    value -= sec->vma;              <-- bytes, needs conversion to octets
    ...
    (*bed->elf_add_symbol_hook) (..., &value))  <-- ???
    ...
    _bfd_elf_merge_symbol (..., &value, ...)    <-- octets
    ...
    _bfd_generic_link_add_one_symbol(..., value, ...)  <-- mixed ???
    ...
    _bfd_elf_add_default_symbol (..., value, ...): _bfd_elf_merge_symbol() <-- octets

  + align = bfd_log2 (isym->st_value);          <-- needs conversion to bytes
  + common_align = bfd_log2 (isym->st_value);   <-- needs conversion to bytes
- elf_link_input_bfd(): Needs 7 conversions
- elf_link_output_extsym(): Needs 4 conversions
- elf_output_implib(): Needs 1 conversion
- elf_s_get_align(): S_GET_ALIGN() <-- ???
- elf_s_set_align(): S_SET_ALIGN() <-- ???
- ldelf_ctf_symbols_iter_cb(): Copies to ctf_link_sym_t::st_value <-- no change
- s_mri_common():
  + align = get_absolute_expression ();
    ...
    S_SET_ALIGN (sym, align);   <-- conversion from bytes to octets

- set_symbol_value(): Needs one conversion
- swap_out_syms(): Needs two conversion


Conclusion: Conversion of elf_internal_sym::st_value from bytes to octets looks
possible, but may discover some currently undefined behavior. Simply converting
everything from bytes to octets in elf_swap_symbol_in/out() could be a shortcut
as currently all non-zero symbol values are in bytes. But doing so would be
inconsistent to my proposed change for r_offset and r_addend, so I would try
the "hard" way.

At next I will have a look at DWARF2 debug information.

Regards
Christian




  parent reply	other threads:[~2020-02-23  9:07 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
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 [this message]
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=13081552.YODp3BJPb1@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).