<div dir="ltr">Huh, I didn't know that gold always handles that as a 32-bit value. I'd love to do the same.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 2, 2016 at 6:40 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 2 August 2016 at 18:29, Rui Ueyama <<a href="mailto:ruiu@google.com">ruiu@google.com</a>> wrote:<br>
> On Tue, Aug 2, 2016 at 3:27 PM, Rafael Espíndola<br>
> <<a href="mailto:llvm-commits@lists.llvm.org">llvm-commits@lists.llvm.org</a>> wrote:<br>
>><br>
>> On 2 August 2016 at 18:03, Davide Italiano <<a href="mailto:davide@freebsd.org">davide@freebsd.org</a>> wrote:<br>
>> > On Tue, Aug 2, 2016 at 5:59 AM, Rafael Espíndola<br>
>> > <<a href="mailto:rafael.espindola@gmail.com">rafael.espindola@gmail.com</a>> wrote:<br>
>> >>> +  next();<br>
>> >>> +  if (Tok.startswith("=0x"))<br>
>> >>> +    return parseHex(Tok.substr(3));<br>
>> >><br>
>> >> This is missing the error check for Value below.<br>
>> >><br>
>> ><br>
>> > My understanding is that we support arbitrary hex values, the<br>
>> > restriction is only for decimal.<br>
>><br>
>> Why?<br>
><br>
><br>
> In this context 0xbeef is different from 0x0000beef. The former is 2 byte<br>
> padding while the latter is 4 bytes.<br>
<br>
</span>I see.<br>
<br>
So, the handling of this in bfd/gold seems to be<br>
<br>
* Decimal and octal denote a 32 bit value.<br>
* Hexadecimal denotes a 32 value on gold.<br>
* The size of the representation is significant in bsd if hexadecimal.<br>
<br>
I wonder if we could get away like gold by always using a 32 bit<br>
value, which would allow a simple use of getAsInteger for all cases.<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>