bfd_octets_per_byte(), relocations and debug sections

[Christian Eggers]

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