This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[ld/testsuite] Skip "Mixing PIC and non-PIC" testcase on ARM/AArch64 if when no -fpie or -fPIE



I'm seeing:

NA->FAIL: Mixing PIC and non-PIC
on aarch64-none-linux-gnu.
You can either fix aarch64 backend or skip the test for aarch64.

H.J,

     For your testcase, AArch64 is not generating dynamic relocation for
     weak undefined symbol referenced from non-pic code when linking
     exectuable, instead, it's resolved to zero during static linking
stage.
     As far as I know, this behavior is exactly what's described here at

       https://sourceware.org/ml/binutils/2008-04/msg00269.html

     And reading those historical discussions,

      https://sourceware.org/ml/binutils/2008-04/msg00032.html
      https://sourceware.org/ml/binutils/2008-02/msg00264.html

     Looks to me the ld behavior changes introduced by your patch is
quite
     sensitive and there still be lack of consensus.
What linker change were you referring to?  I only added a testcase.

I mean those linker changes added together with this testcase.

commit aec6b87e0b66d707ead62ca40d220ee78b4cf5a5
Author: H.J. Lu <hjl.tools@gmail.com>
Date:   Fri Feb 26 04:16:15 2016 -0800

      [x86] Resolve non-PIC undefweak symbols in executable

As far as aarch64 backend is concerned, I only added a testcase.

Well, then why you put it under generic directory? and without restricting
it
on x86? this is implicitly affect all targets, and enforcing all targets to
follow
the changes on x86.  I think similar changes should only be encouraged to
other target
if it's conventional rules, or it's clearly documented by generic or that
target's ELF
specification.

While reading from http://www.skyfree.org/linux/references/ELF_Format.pdf,

   "The link editor does not extract archive members to resolve undefined
   weak symbols. Unresolved weak symbols have a zero value."

Looks to me the spec is even more strict that weak symbol's life is defined
to be ended
after static linking stage. All unresolved weak symbols are assigned zero
value.

IMO, the support of weak symbol under various rare and complex scenarios are
very
target specific, thus I'd either move this testcase under x86 directory or
put it under
generic directory but enabling it on x86 only initially.  If other targets
want and start
to support similar features like x86 on weak symbol, then they can be
enabled seperately.
This looks to me is a more clean & acceptable way to other targets.

Have you looked at the testcase I added? Are there anything
which are target specific?

I do have looked at the testcase, they do be purely C code.

If the convention of generic is syntax generic instead of both syntax and
sematics, I don't have further comment on this.

Anyway, attached patch skips the non-pie version "Mixing PIC and non-PIC"
testcase.

Not sure if it's trivial enough to qualify obvious, so OK for master branch?

2016-03-02  Jiong Wang  <jiong.wang@arm.com>

ld/testsuite/

  * ld-elf/shared.exp (mix_pic_and_non_pic): Only run on ARM and AArch64
    when -fPIE or -fpie specified.
diff --git a/ld/testsuite/ld-elf/shared.exp b/ld/testsuite/ld-elf/shared.exp
index e615f55..909268a 100644
--- a/ld/testsuite/ld-elf/shared.exp
+++ b/ld/testsuite/ld-elf/shared.exp
@@ -589,6 +589,14 @@ proc mix_pic_and_non_pic {cflags ldflags} {
 	set testname "$testname ($cflags $ldflags)"
     }
 
+    if {![string match "-fPIE" $cflags]
+	&& ![string match "-fpie" $cflags]
+	&& ([istarget arm*-*-*]
+	    || [istarget aarch64*-*-*])} {
+      unsupported $testname
+      return
+    }
+
     run_cc_link_tests [list \
 	[list \
 	    "Build libpr19719a.so" \

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]