This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[ld, testsuite] XFAIL "pr20995-2", "Build pr20995-2.so" on arm*-*-eabi*
On 06/01/17 22:41, Alan Modra wrote:
On Fri, Jan 06, 2017 at 06:43:05PM +0000, Szabolcs Nagy wrote:
On 06/01/17 10:47, Kyrill Tkachov wrote:
On 03/01/17 11:56, Alan Modra wrote:
On Tue, Jan 03, 2017 at 11:12:38AM +0100, Christophe Lyon wrote:
For the record, I see failures on some arm targets:
FAIL: Build pr20995-2.so
FAIL: pr20995-2
for arm-netbsdelf and arm-none-eabi
That will be because these tests require working -z relro support, at
least to the point of generating a GNU_RELRO header.
So should these tests be XFAILED on arm targets?
Probably not.
i think arm has -z relro support however PT_GNU_RELRO
header is not emitted if there is no DATA_SEGMENT_RELRO_END
specification in the linker script (which we probably
only have on linux, since shared libs and related features
are not used on baremetal targets).
i assume we could change the arm elf linker script, but
i don't know what are the exact implications of that.
COMMONPAGESIZE needs to be defined in a target's ld/emulparams/ file.
-z relro will then actually do something.
Before doing this you probably should check that the target system
ld.so will not be confused by the presense of a PT_GNU_RELRO header.
(I think current netbsd does support it.)
Since arm-none-eabi is a generic target, anyone using it likely
doesn't create shared libraries. However, I see that shared libs are
supported so you may as well support relro there too.
Thanks for the thoughts.
As discussed on https://sourceware.org/bugzilla/show_bug.cgi?id=20995
For arm*-*-eabi*, I'd be conservative to just XFAIL on it. If one target is
surely doesn't care about disk size, it then can define COMMONPAGESIZE in the
corresponding emulparm file as suggested in this email thread. I can't find
any other harm of defining this constant.
disk size issue
===
If we enable GNU relro support through defining COMMONPAGESIZE in emulparm
then there will be observable impacts on disk size as LD will try to pad text
section sometimes to save one memory page as the pad can avoid the duplicated
mapping of the last page of text segment, this however will cause waste of up to
COMMONPAGESIZE (0x1000 on arm at default) disk size.
for example
===1.s===
.text
.fill 0x4, 1, 0
.data
.fill 0xffd, 1, 0
as -o 1.o 1.s
ld-new.original -o after.exe 1.o -e0
ld-new.after -o before.exe 1.o -e0
disk size before/after 37568/41660, a 4092 bytes increase.
OK for master?
Thanks.
ld/
2017-01-26 Jiong Wang <jiong.wang@arm.com>
* testsuite/ld-elf/elf.exp ("pr20995-2", "Build pr20995-2.so"): XFAIL on
arm*-*-eabi*.
diff --git a/ld/testsuite/ld-elf/elf.exp b/ld/testsuite/ld-elf/elf.exp
index 4d4a631..9ebd125 100644
--- a/ld/testsuite/ld-elf/elf.exp
+++ b/ld/testsuite/ld-elf/elf.exp
@@ -142,6 +142,9 @@ if { [check_shared_lib_support] } then {
{pr20995b.s} {} "pr20995.so"}
}
setup_xfail "tic6x-*-*"
+ # xfail on arm*-*-eabi*. The list can be enlarged to those targets that
+ # don't support GNU_RELRO.
+ setup_xfail "arm*-*-eabi*"
run_ld_link_tests {
{"Build pr20995-2.so"
"-shared -z relro" "" ""
@@ -154,7 +157,7 @@ if { [check_shared_lib_support] } then {
"pr20995" \
"" "tmpdir/pr20995.so" "$AFLAGS_NONPIC" \
{pr20995a.s} {{readelf {-S --wide} pr20995.r}} "pr20995"]]
- setup_xfail "alpha-*-*" "bfin-*-*" "ia64-*-*" "xtensa-*-*"
+ setup_xfail "alpha-*-*" "bfin-*-*" "ia64-*-*" "xtensa-*-*" "arm*-*-eabi*"
run_ld_link_tests [list \
[list \
"pr20995-2" \