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

[Christian Eggers <ceggers@gmx.de>]

Dear Alan,

some hours after my previous message I became doubtful whether the current
state is correct. As SDMA will be the first ELF target with opb>1, I see a
chance for getting things right before more targets appear and everything is
cemented.

Am Sonntag, 16. Februar 2020, 09:22:22 CET schrieb Christian Eggers:
> 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?
>
> > How about r_addend
>
> > and st_value?

As SEC_ELF_OCTETS is only available for BFD programs, mixing bytes and octets
in the external representation (ELF) maybe a poor decision.

Initially everything was in bytes, but this wasn't suitable for DWARF
information as these are only representable in octets. In order to get around
this, I introduced SEC_ELF_OCTETS, which helped to keep the internal
representation (VMA/LMA) in bytes.

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?

Regards
Christian