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

[sourceware.org at aydos dot de]

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

--- Comment #12 from Gökçe Aydos <sourceware.org at aydos dot de> ---
(In reply to Nick Clifton from comment #10)

> >> 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" ?

Simply an array of bits. In other words the memory can store data of arbitrary
width at each address. You have the freedom.

> 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 thought that the objcopy output is for convenient data exchange between gcc
and $readmemh. My hunch is: if the developer has to write a custom data
importer function that can parse the '@address' lines, then they would rather
write their own Verilog-objcopy with convenient features.

> 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...

Yeah I thought about that too, when I was writing my remark :) Your point makes
sense. I just started using the Verilog output, so take my comments with a
grain of salt.

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