[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/21532] New: AArch64: Symbol address inconsistency across compil

From: nickc at redhat dot com
Subject: [Bug ld/21532] New: AArch64: Symbol address inconsistency across compilation units
Date: Tue, 30 May 2017 14:14:46 +0000


            Bug ID: 21532
           Summary: AArch64:  Symbol address inconsistency across
                    compilation units
           Product: binutils
           Version: 2.29 (HEAD)
            Status: NEW
          Severity: critical
          Priority: P2
         Component: ld
          Assignee: unassigned at sourceware dot org
          Reporter: nickc at redhat dot com
  Target Milestone: ---

Created attachment 10074
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10074&action=edit
Demonstration of the bug

The unit test fails on AArch64 and passes on x86-64, s390x and ppc64.

A static const struct (APFloat::IEEEsingle) is defined in the shared library
(libLLVM.so) and accessed both from within the library as well as the
executable that links against the shared library.

On AArch64, taking the address of IEEEsingle yields different results for code
in the executable and code in the shared library.

It looks like the linker creates a copy of IEEEsingle in the executable but
then the GOT entry for IEEEsingle is not updated in libLLVM.so, causing any
accesses to IEEEsingle in libLLVM.so to refer to the original definition (which
in itself is not a big problem as all the data is constant).

However, this breaks the LLVM APFloat class because it uses the addresses of
the various static const structs (IEEEsingle, IEEEdouble, IEEEquad,
x87DoubleExtended, etc. which define the properties of the different floating
point types) to dispatch on the floating point type in the member functions of
APFloat. Thus it is crucial that any of those constants always have the same
address no matter where they are referenced from.

APFloat is an arbitrary precision floating point implementation that is used in
various places across the whole compiler, e.g. there are various codepaths
involving APFloat that will lead to crashes on AArch64.

Running the attached test case should yield the following output on AArch64:

$ ./build.sh
Address of IEEEsingle (APFloatTest.cpp): 0x420208
Address of IEEEsingle (APFloat.cpp)    : 0x3ff78cf0a58

And the following output on x86-64:

$ ./build.sh
Address of IEEEsingle (APFloatTest.cpp): 0x7fbedc3cc9a0
Address of IEEEsingle (APFloat.cpp)    : 0x7fbedc3cc9a0

As you can see the addresses are not consistent on AArch64.

You are receiving this mail because:
You are on the CC list for the bug.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]