[Bug ld/30865] ld: =fillexp different behaviors for hexidecimal literal

[nickc at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=30865

--- Comment #1 from Nick Clifton <nickc at redhat dot com> ---
(In reply to Fangrui Song from comment #0)

> A side effect possibly from this commit is that 0x literals have different
> behaviors from decimal literals and expressions.
> 
> .text : { *(.text) } =0x90        # set the fill pattern to 0x90909090
> .text : { *(.text) } =0x90909090  # set the fill pattern to 0x90909090
> .text : { *(.text) } =144         # set the fill pattern to 0x00000090
> .text : { *(.text) } =0x90+0      # set the fill pattern to 0x00000090
> 
> This has been the case for ~20 years, so probably not worth changing,

Agreed.

> but I
> felt obliged to point out this special behavior to warn users about 0x90
> 0x9090 0x909090 that are shorter than 4 bytes.

So a documentation update is needed.

In the course of investigating this I also discovered that the difference
only applies to simple hexadecimal values specified with a 0x prefix.  It
does not apply to expressions involving hex numbers, eg 0x1 + 0x2, nor to
hex values specified via a $ prefix, eg $9a, nor to hex values specified 
by a letter suffix, eg 9aH, nor to hex values specified with a magnitude,
eg 0x9aK

Anyway please take a look at the uploaded patch which updates the 
documentation and adds a new test case to make sure that the documented
behaviour continues.

-- 
You are receiving this mail because:
You are on the CC list for the bug.