Fixes https://bugs.llvm.org/show_bug.cgi?id=44903
It is about the following case:
```
SECTIONS {
.foo : { *(.foo) } =0x90909090
/DISCARD/ : { *(.bar) }
}
```
Here while parsing the fill expression we treated the
"/" of "/DISCARD/" as operator.
With this change, suggested by Fangrui Song, we do
not allow expressions with operators (e.g. "0x1100 + 0x22")
that are not wrapped into round brackets. It should not
be an issue for users, but helps to resolve parsing ambiguity.
Differential revision: https://reviews.llvm.org/D74687
D64130 introduced a bug described in the following message:
https://reviews.llvm.org/D64130#1571560
The problem can happen with the following script:
SECTIONS {
.out : {
...
FILL(0x10101010)
*(.aaa)
...
}
The current code tries to read (0x10101010) as an expression and
does not break when meets *, what results in a script parsing error.
In this patch, I verify that FILL command's expression always wrapped in ().
And at the same time =<fillexp> expression can be both wrapped or unwrapped.
I checked it matches to bfd/gold.
Differential revision: https://reviews.llvm.org/D64476
llvm-svn: 365635
Executable sections should not be padded with zero by default. On some
architectures, 0x00 is the start of a valid instruction sequence, so can confuse
disassembly between InputSections (and indeed the start of the next InputSection
in some situations). Further, in the case of misjumps into padding, padding may
start to be executed silently.
On x86, the "0xcc" byte represents the int3 trap instruction. It is a single
byte long so can serve well as padding. This change switches x86 (and x86_64) to
use this value for padding in executable sections, if no linker script directive
overrides it. It also puts the behaviour into place making it easy to change the
behaviour of other targets when desired. I do not know the relevant instruction
sequences for trap instructions on other targets however, so somebody should add
this separately.
Because the old behaviour simply wrote padding in the whole section before
overwriting most of it, this change also modifies the padding algorithm to write
padding only where needed. This in turn has caused a small behaviour change with
regards to what values are written via Fill commands in linker scripts, bringing
it into line with ld.bfd. The fill value is now written starting from the end of
the previous block, which means that it always starts from the first byte of the
fill, whereas the old behaviour meant that the padding sometimes started mid-way
through the fill value. See the test changes for more details.
Reviewed by: ruiu
Differential Revision: https://reviews.llvm.org/D30886
Bugzilla: http://bugs.llvm.org/show_bug.cgi?id=32227
llvm-svn: 299635
Previously we failed to parse next scripts because disallowed
a space between filler value and '=':
.text : {
...
} :text = 0x9090
Differential revision: https://reviews.llvm.org/D24831
llvm-svn: 282248
In most cases that means just not checking the address when we don't
need it.
For some tests it is easier to just set . to a known value.
llvm-svn: 281976
Patch implements FILL just as alias for =fillexpr.
This allows to make implementation much shorted and simpler than D24186.
Differential revision: https://reviews.llvm.org/D24227
llvm-svn: 280708
Georgii Rymar