bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug binutils/25202] objcopy --verilog-data-width doesn't respect target


From: sourceware.org at aydos dot de
Subject: [Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
Date: Sun, 06 Nov 2022 08:17:37 +0000

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

--- Comment #9 from Gökçe Aydos <sourceware.org at aydos dot de> ---
I tested the patch (without the test). My remarks:

1) AFAIK memory addresses are byte addresses in gcc. If --verilog-data-width is
greater than 1, then each word in the pattern file becomes something else than
a byte. From the 2017 Systemverilog LRM:

> As the file is read, each number encountered is assigned to a successive word 
> element of the memory.

This means for example:
```
$ riscv64-elf-objcopy my.elf -O verilog --verilog-data-width=4 my.hex
--verilog-data-endianness=input
$ head -2 my.hex
@80000000
FEEDC0B7 EAD08093 FF76E137 F5610113
```

If I load these data using `$readmemh`, then `FEEDC0B7` is stored at address
`8000_0000` (which is correct), but `EAD08093` is stored at `8000_0001` instead
of `8000_0004`:

```
Disassembly of section .text.init:

80000000 <rvtest_entry_point>:
80000000:       feedc0b7                lui     x1,0xfeedc
80000004:       ead08093                addi    x1,x1,-339 # feedbead
```

So additional addressing lines must be generated if --verilog-data-width is
used.

2) wording: endian-ness and endianness seem to be used interchangeably.
Wikipedia uses `endianness`

3) I do not see any advantage of `--verilog-data-endianness={big,little}`. If
the input was compiled for an architecture, I expect that the developer wants
to use the output of objcopy for the same architecture (given that the chosen
architecture works only with a single endianness).

Furthermore I understand that objcopy does not *want* to change the endianness.
>From the manual:

> Note---objcopy is not able to change the endianness of its input files.  If 
> the input format has an endianness (some formats do not), objcopy can only 
> copy the inputs into file formats that have the same endianness or which have 
> no endianness (e.g., srec). (However, see the --reverse-bytes option.)

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]