[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness

[olof.kindgren at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=25202

--- Comment #16 from Olof Kindgren <olof.kindgren at gmail dot com> ---
>> I believe that practically no one has actually used this feature much 
>> because of this bug
>
>I weakly remember that someone from the RISC-V community community hacked 
>their own C program to convert the .elf to a desired Verilog input format.

I think there are about one million different ten-line utilities for converting
bin files to verilog. I have probably at least one in each project I'm working
on myself. Very much looking forward to not need those anymore. :)

>OK, just to make sure that I understand this correctly...
>
>  * If the start address is 0x100 and the data width is 1 then
>    the address in the output file should be "@100".
>
Correct!

>  * If the start address is 0x111 and the data width is 1 then
>    the address in the output file should be "@111".
>
Correct!

>  * If the start address is 0x100 and the data width is 4 then
>    the address in the output file should be "@40".  (ie 0x100 / 4)
>
Correct!

>  * If the start address is 0x111 and the data width is 4 then
>    the address in the output file should be "@44" and the first
>    byte should be a padding byte of 00. 
>
Correct!

>Is that right ?
4 out of 4! :)

Same applies to endings where we need to zero-pad. Now, there's a nasty corner
case here. I'm not super familiar with sections and stuff, but imagine there's
a section (segment?) ending at address 0x9 and then another one starting at
address 0xb. With 4-byte words and padding the first section would be
@0
11223344 55667788 9900000

and the second one
@2
aabbccdd eeff....

meaning that aabbccdd will overwrite 99000000 (I think. Haven't read the
verilog spec close enough tbh). Now, in practice I think this will happen very
rarely, but I wonder if we should only allow sections to start at word
boundraries. As a user I would prefer a limitation with a helpful error message
rather than silently overwriting parts of my code. Probably also keeps down
complexity of the code. From my earlier looks at the objcopy stuff, it's really
built to work on byte-basis so we're already stretching it a bit.

-- 
You are receiving this mail because:
You are on the CC list for the bug.