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: Wed, 02 Nov 2022 15:07:53 +0000

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

gökçe <sourceware.org at aydos dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sourceware.org at aydos dot de

--- Comment #4 from gökçe <sourceware.org at aydos dot de> ---
I had the same problem like Olof while copying a little-riscv32 a verilog
target:


```
$ riscv64-elf-objcopy my.elf -O verilog --verilog-data-width=4 my.hex
$ head -2 my.hex
@80000000
B7C0EDFE 9380D0EA 37E176FF 130161F5
```

I used a oneliner as a workaround:
```
sed -E 's/([^@].)(..)(..)(..)([ $])/\4\3\2\1\5/g' my.hex > my-le.hex
```

> Seeing that bfd_targets are constants and passing the input bfd's endianness 
> to the verilog handler would be a huge code change for what only a single 
> format needs, would the best way to fix this be to create 2 verilog bfd 
> formats? ...

I do not have any experience of binutils source code, but I read in the manual:

> 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

So if the output format cannot dynamically change endianness, then Alex's
proposal makes sense.

Is someone working on this?

-- 
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]