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

[nickc at redhat dot com]

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

--- Comment #10 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Gökçe Aydos from comment #9)
> I tested the patch (without the test). My remarks:

Thanks for testing it.

> 1) AFAIK memory addresses are byte addresses in gcc. If --verilog-data-width
> is greater than 1, then each word in the pattern file becomes something else
> than a byte. From the 2017 Systemverilog LRM:
> 
>> As the file is read, each number encountered is assigned to a successive 
>> word element of the memory.

In that sentence, what exactly is meant by "word" ?

> This means for example:
> ```
> $ riscv64-elf-objcopy my.elf -O verilog --verilog-data-width=4 my.hex
> --verilog-data-endianness=input
> $ head -2 my.hex
> @80000000
> FEEDC0B7 EAD08093 FF76E137 F5610113
> ```
> 
> If I load these data using `$readmemh`, then `FEEDC0B7` is stored at address
> `8000_0000` (which is correct), but `EAD08093` is stored at `8000_0001`
> instead of `8000_0004`:

But isn't this a problem with how you are using the my.hex file ?  If it has
been created with a data width of 4, then the expectation is that it will be
loaded using a mechanism that advances the address by 4 after each reading
each group of 4 bytes ?  So if you want to use `$readmemh` in the way you have
shown, then you *have* to use --verilog-data-width=1.  (Or just leave it
undefined, since a width of 1 is the default).

I admit that I am not an expert on the verilog file format, but that code in
the
BFD library that creates the output has been there for a long time, and if
widths
greater than 1 did not work, I would have expected to have seen bug reports
about
it before now...



> 2) wording: endian-ness and endianness seem to be used interchangeably.
> Wikipedia uses `endianness`

Yeah - I was never sure of the correct spelling, but now that you have
pointed it out, I can correct the sources.


> 3) I do not see any advantage of `--verilog-data-endianness={big,little}`.
> If the input was compiled for an architecture, I expect that the developer
> wants to use the output of objcopy for the same architecture (given that the
> chosen architecture works only with a single endianness).

Yeah - I was unsure about them too.  But there are bi-endian architectures,
so maybe there is a need.  It does seem to be a stretch however.


> Furthermore I understand that objcopy does not *want* to change the
> endianness. From the manual:
> 
>> Note---objcopy is not able to change the endianness of its input files.  If 
>> the input format has an endianness (some formats do not), objcopy can only 
>> copy the inputs into file formats that have the same endianness or which 
>> have no endianness (e.g., srec). (However, see the --reverse-bytes option.)

That sentence is generally true, but I think that the verilog file format is a 
special case, like the srec format.  

But overall I think that I agree with you.  It would be better to simplify the
patch and remove the big/little endian options.  I will attach an updated
patch.

Cheers
  Nick

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