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.
