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

[Christian Eggers]

Am Donnerstag, 27. Februar 2020, 09:35:41 CET schrieb Alan Modra:
> Symbols are a real problem, not because of some implementation detail,
> but because you don't know the units of st_value.  A symbol defined as
> a label on a line of assembly holds an address, but for example a
> symbol defined by
>   sym = 123
> could be a size in octets, an address, or just a plain number.
Maybe this is not the main problem (at least for SDMA). All "plain" numbers in
assembler are most likely bytes. If somebody requires octets in future, a new
".octet <sym>" directive might help...

> I think that if you decide that symbol values should always be octets,
> then you'll eventually come to the conclusion that addresses in the
> assembler need to be octets too.
I've made a short try to store st_value and .debug_line statements in octets.
For this experiment I simply multiplied st_value by 2 in the swap_in and
swap_out functions. While this worked quite well (as all "octet" symbols had a
value of 0), making this change for debug information ended in finally giving
up. It started harmless with expressions which became fixes. But then some of
them became relocations where it is difficult/impossible to know which ones
have to be shifted and which ones not...

> And then it's just easier to dispense with octets_per_byte.
Tried to translate the outcome from German into English: Hindsight is easier
than foresight.

When I started with SDMA, I already had a presentiment that support for
octets_per_byte might be incomplete for ELF/DWARF. But I liked the possibility
of having correct addresses in assembler code and in objdump output and I
didn't want to use the obsolete coff/stabs format.

I suspect that using octets_per_byte=1 for SDMA would complicate things for
the user and additionally would set back my SDMA port by several months (maybe
that I will be unable to complete it in this case).

> So if you're going to keep octets per byte of 2, I wouldn't be trying
> to convert any symbol values.
As I don't want to add further complexity to this, I would like to keep
st_value, r_addend and r_offset like it is for now.


If you are ok with my latest patches, I would like send the first version of
the SDMA port. After working countless weekends on my first binutils port,
it's time to finish...

Regards
Christian