Bug 30865 - ld: =fillexp different behaviors for hexidecimal literal
Summary: ld: =fillexp different behaviors for hexidecimal literal
Status: RESOLVED FIXED
Alias: None
Product: binutils
Classification: Unclassified
Component: ld (show other bugs)
Version: unspecified
: P2 normal
Target Milestone: ---
Assignee: Nick Clifton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-09-18 04:16 UTC by Fangrui Song
Modified: 2023-11-06 14:01 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments
Proposed patch (1.70 KB, patch)
2023-09-18 13:26 UTC, Nick Clifton
Details | Diff
Proposed patch (2.14 KB, patch)
2023-09-18 13:40 UTC, Nick Clifton
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Fangrui Song 2023-09-18 04:16:19 UTC
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.
Comment 1 Nick Clifton 2023-09-18 13:25:53 UTC
(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.
Comment 2 Nick Clifton 2023-09-18 13:26:14 UTC
Created attachment 15114 [details]
Proposed patch
Comment 3 Nick Clifton 2023-09-18 13:39:54 UTC
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.
Comment 4 Nick Clifton 2023-09-18 13:40:14 UTC
Created attachment 15115 [details]
Proposed patch
Comment 5 Fangrui Song 2023-11-05 23:57:39 UTC
(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.
Comment 6 Sourceware Commits 2023-11-06 14:00:33 UTC
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.
Comment 7 Nick Clifton 2023-11-06 14:01:39 UTC
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.