https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #19 from Gökçe Aydos <sourceware.org at aydos dot de> --- Thanks 🎈 The address generation for data-width>1 looks fine in general. I found the following issues: 1) Output is wrong if data-width>16. Test cases: data-width=1: ``` @80000000 B7 C0 ED FE 93 80 D0 EA 37 E1 76 FF 13 01 61 F5 B7 71 BB 7F 93 81 B1 FA 37 B2 DD BF 13 02 52 7D ``` data-width=16: ``` @08000000 F5610113FF76E137EAD08093FEEDC0B7 7D520213BFDDB237FAB181937FBB71B7 ``` 16 bytes correspond to 4 right shifts, so `08000000` is ok. data-width=32 ``` @04000000 F5610113FF76E137EAD08093FEEDC0B7 7D520213BFDDB237FAB181937FBB71B7 ``` Address correct, but not the data :( This is an edge case, but we should handle that. Probably the same behavior for data-widths greater than 32. 2) Error message not helpful ``` $ ... --verilog-data-width=3 riscv64-elf-objcopy: my.memh: invalid operation ``` The error message could be more informative by including that something is wrong with `--verilog-data-width`. --- I could not test unaligned data because I could not figure out how to generate and elf file with unaligned words using gcc and ld :( I fuzzed with `.align 2` in assembler and `. = ALIGN(2)` but the output was always 32 bit aligned. If someone has can send an example assembler and linker code, I can happily test that. -- You are receiving this mail because: You are on the CC list for the bug.
