This is the mail archive of the
mailing list for the binutils project.
Re: [AArch64] Use SYMBOL_REFERENCES_LOCAL in one symbol check
- From: Steve Ellcey <sellcey at cavium dot com>
- To: Jiong Wang <jiong dot wang at foss dot arm dot com>, Binutils <binutils at sourceware dot org>, Nick Clifton <nickc at redhat dot com>
- Date: Tue, 20 Jun 2017 10:50:47 -0700
- Subject: Re: [AArch64] Use SYMBOL_REFERENCES_LOCAL in one symbol check
- Authentication-results: sourceware.org; auth=none
- Authentication-results: foss.arm.com; dkim=none (message not signed) header.d=none;foss.arm.com; dmarc=none action=none header.from=cavium.com;
- References: <email@example.com>
- Reply-to: sellcey at cavium dot com
- Spamdiagnosticmetadata: NSPM
- Spamdiagnosticoutput: 1:99
On Thu, 2017-06-15 at 16:46 +0100, Jiong Wang wrote:
> During fixing copy relocation on AArch64, I noticed for some pc-relative
> relocations, we want to allow them under PIC mode. However the current
> check now looks inaccurate to me. A normal global symbol even defined in
> .so can still bind externally in which case pc-relative relocation is not
> I think SYMBOL_REFERENCES_LOCAL should be used and is more accurate than
> the original individual checks..
> This patch fixed this.
> cross/native binutils/gas/ld/gcc/g++ check OK.
> OK for master?
> 2017-06-15 Jiong Wang <firstname.lastname@example.org>
> * elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Use
This patch is breaking my glibc testing on aarch64. I don't understand
exactly why, but if I run a program 'normally' things seem
to work, but if I run the test by explicitly running the dynamic
linker/loader, then the test segfaults. This is the way things are
run in the glibc testsuite so that libc and other libraries can be
tested without installing them. So, for example, I run a hello world
program like this:
/home/sellcey/toolchain/lib64/ld-2.25.90.so --library-path /home/sellcey/toolchain/lib64 ./x
Then I get a segfault.
If I undo this patch everything works fine. If I copy ld-2.25.90.so
and everything from /home/sellcey/toolchain/lib64 to /lib64 and just
run './x' then things seem to work as well, even with your change in
place. Any idea on what is going on?