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.
