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.