Home Original page

[PATCH v3 0/2] Fix several mix up between octets and bytes in ELF program headers

Christian Eggers ceggers@gmx.de
Sat Feb 22 16:32:00 GMT 2020 
Am Donnerstag, 20. Februar 2020, 02:29:53 CET schrieb Alan Modra:
> On Sun, Feb 16, 2020 at 08:37:43PM +0100, Christian Eggers wrote:
> > But for the ELF file, every program handling it must know which
> > information is in octets or in bytes. For luck, the sizes are already in
> > octets, otherwise I had already trouble with external software. But
> > probably everything should be stored in octets, at least this should
> > resolve the trouble I already have with my external debugger. This
> > debugger has only one symbol space for ARM and SDMA. Having symbols (and
> > debug line info) in octets should make nasty workarounds needless.
> >
> > What is your opinion?
>
> Yes, that is what I'd be inclined to so.  In fact, if faced with
> designing an ABI for your NXP SDMA processor from scratch I'd avoid
> the octets_per_byte conversion entirely by using octets from assembly
> onwards.  Addresses would always be multiples of two, and you'd design
> relocations to suit.  Users of course would need to write ". + 2"
> rather than ". + 1" and similarly in other expressions involving
> addresses.

When I started SDMA development, after some days I stumbled over
"octets_per_byte" and thought that this is the correct way working with
processors which address 16 bit per program counter value. If I had known how
much problems this will cause, maybe I had never tried...

>From the git history it looks like you already took a lot of effort to get
octets_per_byte working. If also found PR19713 (and the following), were Dan
Gissel worked on an ELF port for octets_per_byte=4 (but I don't know any
details). As most of SDMA (including the test suites) currently works fine
with the current OPB setting, I would prefer to keep it that way.

For the ELF representation, I currently study whether using octets everywhere
would be an improvement. Here is what I found so far:

Elf_Internal_Rela::r_offset
----------------------------
Currently, arelent::address is produced by tc_gen_reloc
[sdma_gen_tc_gen_reloc], either as octets or bytes, depending on
SEC_ELF_OCTETS. This is copied to Elf_Internal_Rela::r_offset in
elf_write_relocs().

The inverse happens in elf_slurp_reloc_table_from_section() where
Elf_Internal_Rela::r_offset is copied to arelent::address. The main user is
bfd_perform_relocation(), where address is multiplied with
bfd_octets_per_byte (..., input_section).

Possible change: Keep arelent::address as it is, change
Elf_Internal_Rela::r_offset to octets. Change the data type of r_offset to a
new type (e.g. bfd_octet) in order to annotate the unit.

Users of Elf_Internal_Rela::r_offset:
- _bfd_elf_discard_section_eh_frame(): /* FIXME: octets_per_byte.  */
- _bfd_elf_parse_eh_frame()
  + ENSURE_NO_RELOCS(): /* FIXME: octets_per_byte.  */
  + SKIP_RELOCS() : /* FIXME: octets_per_byte.  */
  + GET_RELOC(): /* FIXME: octets_per_byte.  */
- bfd_elf_perform_complex_relocation(): Calls bfd_octets_per_byte(..., sec)
- bfd_elf_reloc_symbol_deleted_p(): called by
  + _bfd_discard_section_stabs(): unsure, may need conversion to octets?
  + _bfd_elf_discard_section_eh_frame(): /* FIXME: octets_per_byte.  */
- elf_swap_reloc(a)_in/out(): No change
- elf_write_relocs(): Change: Convert arelent::address to octets.
- elf_gc_smash_unused_vtentry_relocs(): Currently buggy, hend is composed of
bytes and octets.
- elf_link_input_bfd():
  + Needs four conversions
  + Called function _bfd_elf_section_offset() should return octets
- elf_link_read_relocs_from_section(): Only printfs
- elf_link_sort_cmp1(): No change
- elf_link_sort_cmp2(): No change
- elf_link_sort_relocs(): Copy to elf_link_sort_rela::offset, should also be
converted (trivial).
- elf_reloc_link_order(): Needs one conversion
- elf_slurp_reloc_table_from_section(): Needs two conversions
- mark_entry():  /* FIXME: octets_per_byte.  */
Other users are in readelf.c which would probably be more happy with octets
(at least if debug_info also is).


Conclusion: "Changing" Elf_Internal_Rela::r_offset to octets would probably
remove more FIXMEs than it creates.

Bonus question: What about Elf_Internal_Rela::r_offset?
For me it looks like this should be kept as it is.

I will investigate the other ELF variables in a further email (after the kids
are finished shouting through the house).

Regards
Christian
More information about the Binutils mailing list