<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Aug 4, 2016 at 1:45 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 4 August 2016 at 16:18, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> My observation is different; gold handles numbers starting with 0x as a<br>
> binary of arbitrary size in hexstring. How did you test it?<br>
<br>
<br>
</span>With an assembly file with just<br>
<br>
        .align 16<br>
        .long 42<br>
<br>
a linker script with<br>
<br>
SECTIONS<br>
{<br>
  .text : {*(.text) } = 0xa<br>
}<br>
<br>
and linking with<br>
<br>
ld.gold -T  test.script test.o test.o  -shared -o test.gold<br>
<br>
I get a file with a .text section that looks like<br>
<br>
 0x000000d0 2a000000 0000000a 0000000a 0000000a *...............<br>
 0x000000e0 2a000000<br></blockquote><div><br></div><div>Ah, right. I was accidentally using ld.bfd. Confirmed that gold handles hexstrings as 32-bit values. We probably should do the same.</div></div></div></div>