Fwd: bfd_octets_per_byte(), relocations and debug sections

[Timothy Wall <runedelve at gmail dot com>]

I wrote the original TI stuff, which introduced octets_per_byte (which at
the time was just “2” for those targets. I’m not sure when or why “_POWER”
was introduced.

Since the TI targets are the only ones using it (and I’m not sure those
CPUs are still being produced), you shouldn’t worry too much if you need to
tweak the model to make it work properly.

On Wed, Jun 27, 2018 at 11:41 PM Christian Eggers <ceggers@gmx.de> wrote:

> Dear binutils developers,
>
> I'm trying to port binutils to a new architecture (SDMA controller found
> on
> NXPs i.MX series processors).
>
> For this processor, each increment of the PC by one addresses another 16
> bit
> instruction word. So I assume that bfd_arch_info_type::bits_per_byte has
> to be
> set to 16 and OCTETS_PER_BYTE_POWER to 1. This seems to be something
> special,
> because in binutils I found only tic4x and tic54x, where bits_per_byte is
> different from 8 and OCTETS_PER_BYTE_POWER is different from 0.
>
> With these settings, some addresses/sizes in the resulting .o or .elf
> files are
> also represented in quantities of 16 bit. So the size of a 32 bit variable
> is
> 2 (at least for some fields). Due to the low number of architectures where
> this
> is the case, I'm unsure whether this has been done by intention or by
> chance.
>
> Problems comes up when assembling with debug information. It looks that
> debug
> information are always emitted in units of 8 bit, regardless of
> bits_per_byte
> or OCTETS_PER_BYTE_POWER. The following issues arises for my platform:
>
> 1.) Debug sections with an uneven size where cropped by one byte. This
> could
> be easily fixed by padding the section size to the next even value, but
> some
> routines in objdump are not aware of this and read garbage data.
> 2.) Internal length fields within debug sections are calculated in 16 bit
> quantities instead of 8 bit. But the dwarf2 parsing code expects 8-bit
> quantities.
> 3.) (Some) relocation values are wrong.
> 4.) The last significant bit of uneven relocation addresses are lost. So
> some
> relocations within debug section are performed at a wrong (minus one byte)
> position.
> 5.) ...
>
> Summary: 8-bit organized debug information does not fit well within 16-bit
> organized files.
>
> Question: Is there a reason, not to use 8 bit based relocation addresses
> and
> (section-) sizes? Can this be changed, even if breaking binary
> compatibility
> for two architectures? Is there an alternative way to fix this?
>
> In the ELF specification I could not find much concrete information about
> this
> topic:
>
> > Object files therefore represent some control data with a
> machine-independent
> > format, making it possible to identify object files and interpret their
> > contents in a common way. Remaining data in an object file use the
> encoding
> > of the target processor, regardless of the machine on which the file was
> > created.
>
> The field Elf32_Ehdr::e_ehsize ("ELF header's size in bytes") seems to
> have 8
> bit quantities also for my target. So why is Elf32_Rel::r_offset
> ("the value is the byte offset from") in OCTETS_PER_BYTE quantities?
>
> regards
> Christian
>
>
>