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
next prev 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).