[lld] r277222 - [LinkerScript] Filler can have a decimal value.

[Rui Ueyama via llvm-commits]

Huh, I didn't know that gold always handles that as a 32-bit value. I'd
love to do the same.

On Tue, Aug 2, 2016 at 6:40 PM, Rafael Espíndola <rafael.espindola at gmail.com
> wrote:

> On 2 August 2016 at 18:29, Rui Ueyama <ruiu at google.com> wrote:
> > On Tue, Aug 2, 2016 at 3:27 PM, Rafael Espíndola
> > <llvm-commits at lists.llvm.org> wrote:
> >>
> >> On 2 August 2016 at 18:03, Davide Italiano <davide at freebsd.org> wrote:
> >> > On Tue, Aug 2, 2016 at 5:59 AM, Rafael Espíndola
> >> > <rafael.espindola at gmail.com> wrote:
> >> >>> +  next();
> >> >>> +  if (Tok.startswith("=0x"))
> >> >>> +    return parseHex(Tok.substr(3));
> >> >>
> >> >> This is missing the error check for Value below.
> >> >>
> >> >
> >> > My understanding is that we support arbitrary hex values, the
> >> > restriction is only for decimal.
> >>
> >> Why?
> >
> >
> > In this context 0xbeef is different from 0x0000beef. The former is 2 byte
> > padding while the latter is 4 bytes.
>
> I see.
>
> So, the handling of this in bfd/gold seems to be
>
> * Decimal and octal denote a 32 bit value.
> * Hexadecimal denotes a 32 value on gold.
> * The size of the representation is significant in bsd if hexadecimal.
>
> I wonder if we could get away like gold by always using a 32 bit
> value, which would allow a simple use of getAsInteger for all cases.
>
> Cheers,
> Rafael
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160802/e145a364/attachment.html>