ld: Fix issue where PROVIDE overrides defined symbol
In a linker script, a sequence like this:
foo = ADDR (.some_section);
bar = foo;
PROVIDE (foo = 0);
will result in 'bar = ADDR (.some_section)' and 'foo = 0', which seems
like incorrect behaviour, foo is clearly defined elsewhere, and so the
PROVIDE should not trigger.
The problem is that an expression like this:
foo = ADDR (.some_section);
can't be evaluated until a late phase of the linker, due to the need
for the section '.some_section' to have been placed, then the PROVIDE
was being marked as being used during an earlier phase. At the end of
the link, both lines:
foo = ADDR (.some_section);
PROVIDE (foo = 0);
are active, and this causes the final value of 'foo' to be 0.
The solution proposed in this commit is that, during earlier phases of
the linker, when we see the expression 'foo = ADDR (.some_section);',
instead of ignoring the expression, we create a "fake" definition of
'foo'. The existence of this "fake" definition prevents the PROVIDE
from being marked used, and during the final phase the real definition
of 'foo' will replace the "fake" definition.
The new test provide-6 covers the exact case described above. The
provide-7 test is similar to the above, but using constant
expressions, this was never broken, but is added here to increase
coverage.
The provide-8 case also didn't fail before this commit, but I did
manage to break this case during development of this patch. This case
was only covered by a mmix test before, so I've added this here to
increase coverage.
ld/ChangeLog:
* ldexp.c (exp_fold_tree_1): Rework condition underwhich provide
nodes are ignored in the tree walk, and move the location at which
we change provide nodes into provided nodes.
(exp_init_os): Add etree_provided.
* testsuite/ld-scripts/provide-6.d: New file.
* testsuite/ld-scripts/provide-6.t: New file.
* testsuite/ld-scripts/provide-7.d: New file.
* testsuite/ld-scripts/provide-7.t: New file.
* testsuite/ld-scripts/provide-8.d: New file.
* testsuite/ld-scripts/provide-8.t: New file.
2017-04-28 01:05:08 +08:00
|
|
|
#source: provide-5.s
|
|
|
|
|
#ld: -T provide-8.t
|
Remove run_dump_test support for objcopy as a dump program
We have three copies of run_dump_test in the testsuite. This is a first
step towards consolidating them.
A few tests use objcopy to convert to verilog or srec output, then
check that output is as expected. Those tests can just as easily use
objdump, keeping the set of dump programs (addr2line, nm, objdump,
readelf, size) separate from utilities under test. That in turn makes
auto-detecting the dump program possible in more places.
binutils/
* testsuite/binutils-all/group-7a.d,
* testsuite/binutils-all/group-7b.d,
* testsuite/binutils-all/group-7c.d,
* testsuite/binutils-all/symbols-1.d,
* testsuite/binutils-all/symbols-2.d,
* testsuite/binutils-all/symbols-3.d,
* testsuite/binutils-all/symbols-4.d: Remove DUMPPROG.
gas/
* testsuite/gas/mri/char.d: Don't objcopy to srec, objdump instead.
* testsuite/gas/mri/float.d: Likewise.
* testsuite/lib/gas-defs.exp (run_dump_test): Remove support
for objcopy as a dump tool.
ld/
* testsuite/ld-elf/interleave-0.d,
* testsuite/ld-elf/interleave-4.d: Don't objcopy to srec,
objdump instead.
* testsuite/ld-gc/all-debug-sections.d,
* testsuite/ld-scripts/provide-4.d,
* testsuite/ld-scripts/provide-5.d,
* testsuite/ld-scripts/provide-6.d,
* testsuite/ld-scripts/provide-7.d,
* testsuite/ld-scripts/provide-8.d,
* testsuite/ld-scripts/segment-start.d: Remove PROG, specify
nm instead.
* testsuite/lib/ld-lib.exp (run_dump_test): Remove support
for objcopy as a dump tool.
2018-09-13 13:13:34 +08:00
|
|
|
#nm: -B
|
2020-08-27 19:58:27 +08:00
|
|
|
#xfail: mmix-*-* *-*-pe spu-*-* *-*-mingw* *-*-cygwin
|
ld: Fix issue where PROVIDE overrides defined symbol
In a linker script, a sequence like this:
foo = ADDR (.some_section);
bar = foo;
PROVIDE (foo = 0);
will result in 'bar = ADDR (.some_section)' and 'foo = 0', which seems
like incorrect behaviour, foo is clearly defined elsewhere, and so the
PROVIDE should not trigger.
The problem is that an expression like this:
foo = ADDR (.some_section);
can't be evaluated until a late phase of the linker, due to the need
for the section '.some_section' to have been placed, then the PROVIDE
was being marked as being used during an earlier phase. At the end of
the link, both lines:
foo = ADDR (.some_section);
PROVIDE (foo = 0);
are active, and this causes the final value of 'foo' to be 0.
The solution proposed in this commit is that, during earlier phases of
the linker, when we see the expression 'foo = ADDR (.some_section);',
instead of ignoring the expression, we create a "fake" definition of
'foo'. The existence of this "fake" definition prevents the PROVIDE
from being marked used, and during the final phase the real definition
of 'foo' will replace the "fake" definition.
The new test provide-6 covers the exact case described above. The
provide-7 test is similar to the above, but using constant
expressions, this was never broken, but is added here to increase
coverage.
The provide-8 case also didn't fail before this commit, but I did
manage to break this case during development of this patch. This case
was only covered by a mmix test before, so I've added this here to
increase coverage.
ld/ChangeLog:
* ldexp.c (exp_fold_tree_1): Rework condition underwhich provide
nodes are ignored in the tree walk, and move the location at which
we change provide nodes into provided nodes.
(exp_init_os): Add etree_provided.
* testsuite/ld-scripts/provide-6.d: New file.
* testsuite/ld-scripts/provide-6.t: New file.
* testsuite/ld-scripts/provide-7.d: New file.
* testsuite/ld-scripts/provide-7.t: New file.
* testsuite/ld-scripts/provide-8.d: New file.
* testsuite/ld-scripts/provide-8.t: New file.
2017-04-28 01:05:08 +08:00
|
|
|
|
|
|
|
|
#...
|
|
|
|
|
0+4000 D __FOO
|
|
|
|
|
#...
|
