https://sourceware.org/binutils/docs/ld/Output-Section-Fill.html https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=2c382fb6f5499e01ce83c221f4b35f39e5b414f0 (Feb 2002) added support for arbitrary length fill patterns, e.g. SECTIONS { .text : { *(.text) }=0x0102030405060708 } 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, but I felt obliged to point out this special behavior to warn users about 0x90 0x9090 0x909090 that are shorter than 4 bytes.
(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.
Created attachment 15114 [details] Proposed patch
It is always the way - you post a patch and then immediately realise that you have forgotten something. In this case my patch updates the description of the FILL directive in the linker documentation, but it does not update the =<FILL> expression description. So here is a revised patch that does just that.
Created attachment 15115 [details] Proposed patch
(In reply to Nick Clifton from comment #4) > Created attachment 15115 [details] > Proposed patch Sorry for the late reply but the documentation and test change looks great! There is a minor typo below > + FILL (0x94K) # A hex value with a manitude suffix zero extends - fills with 00 02 50 00 and `fills with `/`fills with:` can probably be used consistently.
The master branch has been updated by Nick Clifton <nickc@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f1837d9c3f2dc2a5c232f4eae4c4bd5a7f77baf8 commit f1837d9c3f2dc2a5c232f4eae4c4bd5a7f77baf8 Author: Nick Clifton <nickc@redhat.com> Date: Mon Nov 6 13:59:53 2023 +0000 ld: =fillexp different behaviors for hexidecimal literal PR 30865 * ld.texi: Update description of the FILL command. * testsuite/ld-scripts/fill2.d: New test. * testsuite/ld-scripts/fill2.t: New test source. * testsuite/ld-scripts/data.exp: Run the new test.
Thanks for the typo correction. I have updated the comments in the test script to make them more uniform, and then checked in the patch.