https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #3 from Liwei.Ma at armchina dot com --- Hi, Alex, I also confirm this bug, while my version seems to be stuck at little endian. I am using ubuntu 20.04.3 package, aarch64-linux-gnu-objcopy (2.34), aarch64-linux-gnu-gcc (9.3.0). And I would report another issue that, the Verilog hex address is for Verilog readmemh, not for OS byte based address. When the -verilog-width=N(byte), the address should be `address / N`. For example, when Verilog-width=8(byte), and the Verilog mem being `reg[63:0] mem[depth]`, the addresses in hex file should be divided by 8. Another convenience issue is for objcopy add an option of `base address`. This should be implemented in readmemh, but it is more convenient here too. The current hex output uses the address in a whole space, while Verilog mem is usually small. It is convenient to subtract a base address when output Verilog hex file. For example, the object address is at 0x004000b0, and option `base address` is set 0x00400000, then the output hex file start at 0x00b0. A small Verilog memory can hold the object data. I am willing to offer some help in the development given me some basic education of objectcopy and detailed tasks. Best regards, Liwei Ma. IMPORTANT NOTICE: The contents of this email and any attachments may be privileged and confidential. If you are not the intended recipient, please delete the email immediately. It is strictly prohibited to disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. (c)Arm Technology (China) Co., Ltd copyright and reserve all rights. ????????????????????????????????????????????????????????????????????????????????????????????????????????????????? (c)???????????? ???????????? -- You are receiving this mail because: You are on the CC list for the bug.
