https://sourceware.org/bugzilla/show_bug.cgi?id=25202
--- Comment #16 from Olof Kindgren <olof.kindgren at gmail dot com> --- >> I believe that practically no one has actually used this feature much >> because of this bug > >I weakly remember that someone from the RISC-V community community hacked >their own C program to convert the .elf to a desired Verilog input format. I think there are about one million different ten-line utilities for converting bin files to verilog. I have probably at least one in each project I'm working on myself. Very much looking forward to not need those anymore. :) >OK, just to make sure that I understand this correctly... > > * If the start address is 0x100 and the data width is 1 then > the address in the output file should be "@100". > Correct! > * If the start address is 0x111 and the data width is 1 then > the address in the output file should be "@111". > Correct! > * If the start address is 0x100 and the data width is 4 then > the address in the output file should be "@40". (ie 0x100 / 4) > Correct! > * If the start address is 0x111 and the data width is 4 then > the address in the output file should be "@44" and the first > byte should be a padding byte of 00. > Correct! >Is that right ? 4 out of 4! :) Same applies to endings where we need to zero-pad. Now, there's a nasty corner case here. I'm not super familiar with sections and stuff, but imagine there's a section (segment?) ending at address 0x9 and then another one starting at address 0xb. With 4-byte words and padding the first section would be @0 11223344 55667788 9900000 and the second one @2 aabbccdd eeff.... meaning that aabbccdd will overwrite 99000000 (I think. Haven't read the verilog spec close enough tbh). Now, in practice I think this will happen very rarely, but I wonder if we should only allow sections to start at word boundraries. As a user I would prefer a limitation with a helpful error message rather than silently overwriting parts of my code. Probably also keeps down complexity of the code. From my earlier looks at the objcopy stuff, it's really built to work on byte-basis so we're already stretching it a bit. -- You are receiving this mail because: You are on the CC list for the bug.
