public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [PATCH] bfd: verilog hex dump backend should handle 64-bit addresses
@ 2020-09-15  6:17 Anatoly Parshintsev
  2020-09-16 12:19 ` Nick Clifton
  0 siblings, 1 reply; 2+ messages in thread
From: Anatoly Parshintsev @ 2020-09-15  6:17 UTC (permalink / raw)
  To: binutils

I observed that `objcopy -O verilog in.o out.dump` command does truncate
the high part of an 64-bit address. The problem can be demonstrated with
the following sequence of commands (bash):

```
  printf '.section the_section, \"a\"\n.byte 0xff\n' |            \
     as -o /tmp/a.o &&                                            \
     ld --section-start=the_section=0x80000000 --defsym=_start=0  \
     /tmp/a.o -o /tmp/final.o &&                                  \
     objcopy -O verilog  /tmp/final.o /tmp/final.v &&             \
     cat /tmp/final.v

  printf '.section the_section, \"a\"\n.byte 0xff\n' |            \
     as -o /tmp/a.o &&                                            \
     ld --section-start=the_section=0x800000000 --defsym=_start=0 \
     /tmp/a.o -o /tmp/final.o &&                                  \
     objcopy -O verilog  /tmp/final.o /tmp/final.v &&             \
     cat /tmp/final.v
```

The output will be:

```
  @80000000
  FF
  @00000000
  FF
```

This is clearly wrong as the second address gets truncated.

When the suggested patch is applied, the output is expected to be:

```
        @0000000800000000
        FF
```

I've run the existing tests (only Binutils-related; `make check`) to make sure
that no regression is introduced.

I considered extending an existing testsuite, but given that it requires
usage of several tools: as, linker and objcopy - I've discarded the idea
since it seems like the result will be too complex
(compared to the existing objcopy tests).

bfd/ChangeLog:
2020-09-14  Anatoly Parshintsev <kupokupokupopo@gmail.com>

       * verilog.c (verilog_write_address): Properly handle 64-bit addresses
       to avoid truncation of the high part.
---
 bfd/verilog.c | 18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/bfd/verilog.c b/bfd/verilog.c
index 9f22bc36bb..a40c89a349 100644
--- a/bfd/verilog.c
+++ b/bfd/verilog.c
@@ -165,12 +165,30 @@ verilog_set_section_contents (bfd *abfd,
 static bfd_boolean
 verilog_write_address (bfd *abfd, bfd_vma address)
 {
+#ifdef BFD64
+  char buffer[20];
+#else
   char buffer[12];
+#endif
+
   char *dst = buffer;
   bfd_size_type wrlen;

   /* Write the address.  */
   *dst++ = '@';
+#ifdef BFD64
+  if (address >= (bfd_vma)1 << 32)
+    {
+      TOHEX (dst, (address >> 56));
+      dst += 2;
+      TOHEX (dst, (address >> 48));
+      dst += 2;
+      TOHEX (dst, (address >> 40));
+      dst += 2;
+      TOHEX (dst, (address >> 32));
+      dst += 2;
+    }
+#endif
   TOHEX (dst, (address >> 24));
   dst += 2;
   TOHEX (dst, (address >> 16));
--
2.20.1

^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: [PATCH] bfd: verilog hex dump backend should handle 64-bit addresses
  2020-09-15  6:17 [PATCH] bfd: verilog hex dump backend should handle 64-bit addresses Anatoly Parshintsev
@ 2020-09-16 12:19 ` Nick Clifton
  0 siblings, 0 replies; 2+ messages in thread
From: Nick Clifton @ 2020-09-16 12:19 UTC (permalink / raw)
  To: Anatoly Parshintsev, binutils

Hi Anatoly,

> I observed that `objcopy -O verilog in.o out.dump` command does truncate
> the high part of an 64-bit address.

Thanks for the bug report and patch.  I have now checked it in.

Cheers
  Nick

PS.  In the future please could report binutils bugs via the sourceware
bugzilla system:

 https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2020-09-16 12:19 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-09-15  6:17 [PATCH] bfd: verilog hex dump backend should handle 64-bit addresses Anatoly Parshintsev
2020-09-16 12:19 ` Nick Clifton

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).