https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #9 from Gökçe Aydos <sourceware.org at aydos dot de> ---
I tested the patch (without the test). My remarks:
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.
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`:
```
Disassembly of section .text.init:
80000000 <rvtest_entry_point>:
80000000: feedc0b7 lui x1,0xfeedc
80000004: ead08093 addi x1,x1,-339 # feedbead
```
So additional addressing lines must be generated if --verilog-data-width is
used.
2) wording: endian-ness and endianness seem to be used interchangeably.
Wikipedia uses `endianness`
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).
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.)
--
You are receiving this mail because:
You are on the CC list for the bug.
