[Bug binutils/27214] New: Outputting hex file with --verilog-data-width 4 uses incorrect offsets

[shareef at jalloq dot co.uk]

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

            Bug ID: 27214
           Summary: Outputting hex file with --verilog-data-width 4 uses
                    incorrect offsets
           Product: binutils
           Version: 2.34
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: binutils
          Assignee: unassigned at sourceware dot org
          Reporter: shareef at jalloq dot co.uk
  Target Milestone: ---

I'm using the gcc-arm-none-eabi-9-2020-q2-update version of objcopy and trying
to output a hex file for Verilog simulation using $readmemh.

It looks like the --verilog-data-width switch outputs the correct size data
chunks but doesn't update the address offsets.

If using the default options of:

  arm-none-eabi-objcopy -S source.o -O verilog source.hex

I can load a byte array using $readmemh with no issue.  If I specify the
following:

  arm-none-eabi-objcopy -S source.o -O verilog --verilog-data-width 4
source.32.hex

then I get 32-bit words but the indexes don't seem to be updated.  When I try
to run the simulator, the array index runs off the end of the array.

Looking at the two output hex files, the first filled address is 0x0 which is
fine.  The next region seems to be set to the same value for both data widths
which is obviously broken.

source.32.hex:
@0000265C
ACDDFF7F 01000000 

source.hex
@0000265C
AC DD FF 7F 01 00 00 00

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