-
Notifications
You must be signed in to change notification settings - Fork 446
verilog options added to binutils objcopy #168
Comments
Thanks, that sounds neat. It looks like it's proceeding through upstream well, so I assume it'll eventually land in a branch that we base releases off of. I think this might be a better topic for the RISC-V mailing lists, as it's not really a bug in riscv-tools, so I'm closing the bug. |
Oh, I guess I just forgot what year it is -- the patch is actually pretty out of date. I'll ping the binutils people. |
I find this patch useful, too, and it looks like it wasn't merged. |
The patch still needs more work before it can be merged. This probably should be discussed in the binutils mailing lists, not here. |
Would you know who/where I can link this conversation to? I appreciate any help getting this functionality implemented. |
Your first message points at a FSF binutils bug report. That is where the patch needs to be discussed. The patch needs to be fixed and merged upstream, and then it will eventually end up in riscv-binutils-gdb. |
Fixed upstream. |
Unfortunately we are not quite there yet https://sourceware.org/bugzilla/show_bug.cgi?id=25202 |
This exatly what I see, endianness is incorrect when I try to objcopy to hex file verilog target |
I spent some time last week trying to fix this to work with both BE and LE architectures but couldn't get it to work. Thought I had it nailed down with @@ -380,8 +382,13 @@ const bfd_target verilog_vec =
{
"verilog", /* Name. */
bfd_target_verilog_flavour,
- BFD_ENDIAN_UNKNOWN, /* Target byte order. */
- BFD_ENDIAN_UNKNOWN, /* Target headers byte order. */
+#if TARGET_BIG_ENDIAN
+ BFD_ENDIAN_BIG, /* Target byte order. */
+ BFD_ENDIAN_BIG, /* Target headers byte order. */
+#else
+ BFD_ENDIAN_LITTLE, /* Target byte order. */
+ BFD_ENDIAN_LITTLE, /* Target headers byte order. */
+#endif
(HAS_RELOC | EXEC_P | /* Object flags. */
HAS_LINENO | HAS_DEBUG |
HAS_SYMS | HAS_LOCALS | WP_TEXT | D_PAGED),
but it broke some assumptions about endianness in other places in the code for BE targets. Would very much appreciate if someone with better knowledge of binutils could take a look. Perhaps it would be easier in the end to just add an explicit endianness switch to the verilog output mode |
I would suggest having this discussion upstream, preferably in the existing bug report. I'm probably the only one with binutils expertise reading this, and I'm hopelessly overloaded with things to fix, so I have no plans to work on this. But there may be other binutils developers that have time to work on it. Note that some targets support both big and little endian as a run time switch. So hard coding endianness here as a build time constant can't work. Sifive has its own program for converting binaries to verilog. It would be nice if someone fixed binutils, but you can always try using the sifive program instead. |
Hello,
This patch
https://sourceware.org/bugzilla/show_bug.cgi?id=19921
I found to be useful for adding enable specification of data width when writing verilog hex format.
as it is right now verilog's $readmemh() will only read the current version of objcopy -d verilog as bytes only.
Thanks,
Donato
The text was updated successfully, but these errors were encountered: