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: alexander.underwood at okstate dot edu
Subject: [Bug binutils/25202] objcopy --verilog-data-width doesn't respect target's endianness
Date: Thu, 21 Oct 2021 16:45:32 +0000

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

Alex Underwood <alexander.underwood at okstate dot edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alexander.underwood@okstate
                   |                            |.edu

--- Comment #2 from Alex Underwood <alexander.underwood at okstate dot edu> ---
Hello,

I can also confirm this bug (still present in 2.37.50), and because the verilog
output functionality is relevant to my work I figured I would take a crack at
fixing it.

As Olof said, the issue does seem to be because the verilog bfd_target uses
BFD_ENDIAN_UNKNOWN, so the little-endianness check in the verilog_write_record
function always fails and falls through to big-endian.  That being said,
verilog_write_record does support big- and little-endian, it just never reaches
the little-endian section.

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?  For
example, a verilog-be and verilog-le format that use BFD_ENDIAN_BIG and
BFD_ENDIAN_LITTLE respectively.  This would leave it up to the user to specify
the correct endianness for their given input bfd but at the same time I feel
would help to alleviate an issue I've seen in several RISC-V projects in
particular that take advantage of this bug and use objcopy as a way of
switching endianness rather than just compiling the original files with the
correct endianness setting at the GCC level.

If that sounds like a reasonable approach, I'll get going on a patch to set
that up.  Though, that does leave the question of what to do with the current
"verilog" target if it ends up split into 2 separate targets.

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