Bug 1215546 - AC_CHECK_SIZEOF(long long, 8) conftest linked with ld.gold crashes on aarch64
Summary: AC_CHECK_SIZEOF(long long, 8) conftest linked with ld.gold crashes on aarch64
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: binutils
Version: rawhide
Hardware: aarch64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Nick Clifton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: ARM64, F-ExcludeArch-aarch64 ghc-8.0 ghc-7.10.3
TreeView+ depends on / blocked
 
Reported: 2015-04-27 05:31 UTC by Jens Petersen
Modified: 2016-05-26 07:10 UTC (History)
3 users (show)

Fixed In Version: binutils-2.25-8.fc22
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-06-21 00:17:57 UTC
Type: Bug


Attachments (Terms of Use)
conftest.c for "AC_CHECK_SIZEOF(long long, 8)" (2.60 KB, text/x-csrc)
2015-04-27 05:31 UTC, Jens Petersen
no flags Details
aarch64 object file (2.14 KB, application/x-object)
2015-04-27 05:49 UTC, Jens Petersen
no flags Details
Working dynamic conftest executable (2.74 KB, application/x-bzip)
2015-05-06 09:44 UTC, Nick Clifton
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1195231 None None None Never

Internal Links: 1195231

Description Jens Petersen 2015-04-27 05:31:56 UTC
Created attachment 1019225 [details]
conftest.c for "AC_CHECK_SIZEOF(long long, 8)"

Description of problem:
While trying to build ghc with ld.gold on aarch64,
I noticed (with ghc-7.10+) that the conftest.c for
AC_CHECK_SIZEOF(long long, 8) in its configure.ac
crashes immediately on aarch64 when linked with ld.gold
(this was originally mentioned in bug 1203057).

Version-Release number of selected component (if applicable):
binutils-2.25-8.fc23

How reproducible:
100%

Steps to Reproduce:
$ /usr/bin/gcc -o conftest -fuse-ld=gold conftest.c

Actual results:
$ ./conftest
Killed
$ gdb ./conftest
(gdb) r
Starting program: /home/petersen/conftest 
During startup program terminated with signal SIGKILL, Killed.

Expected results:
no crash

Additional info:

Comment 1 Jens Petersen 2015-04-27 05:41:48 UTC
I am not sure how to capture the command line used to invoke gold.
"gcc -v -o conftest -fuse-ld=gold conftest.c" does not seem to output
an explicit ld.gold invocation.

Comment 2 Jens Petersen 2015-04-27 05:49:46 UTC
Created attachment 1019235 [details]
aarch64 object file

conftest.o captured with "gcc -save-temps -o conftest -fuse-ld=gold conftest.c"

Comment 3 Jens Petersen 2015-04-27 05:54:32 UTC
Here is the gcc -v output anyway for good measure:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/aarch64-redhat-linux/4.9.2/lto-wrapper
Target: aarch64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-aarch64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-aarch64-redhat-linux/cloog-install --enable-gnu-indirect-function --build=aarch64-redhat-linux
Thread model: posix
gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-o' 'conftest' '-fuse-ld=gold' '-mlittle-endian' '-mabi=lp64'
 /usr/libexec/gcc/aarch64-redhat-linux/4.9.2/cc1 -quiet -v conftest.c -quiet -dumpbase conftest.c -mlittle-endian -mabi=lp64 -auxbase conftest -version -fuse-ld=gold -o /tmp/ccMUpatn.s
GNU C (GCC) version 4.9.2 20150212 (Red Hat 4.9.2-6) (aarch64-redhat-linux)
	compiled by GNU C version 4.9.2 20150212 (Red Hat 4.9.2-6), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/lib/gcc/aarch64-redhat-linux/4.9.2/include-fixed"
ignoring nonexistent directory "/usr/lib/gcc/aarch64-redhat-linux/4.9.2/../../../../aarch64-redhat-linux/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/aarch64-redhat-linux/4.9.2/include
 /usr/local/include
 /usr/include
End of search list.
GNU C (GCC) version 4.9.2 20150212 (Red Hat 4.9.2-6) (aarch64-redhat-linux)
	compiled by GNU C version 4.9.2 20150212 (Red Hat 4.9.2-6), GMP version 6.0.0, MPFR version 3.1.2, MPC version 1.0.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9d00026f4ad4c5ca24956658dd9d77f0
COLLECT_GCC_OPTIONS='-v' '-o' 'conftest' '-fuse-ld=gold' '-mlittle-endian' '-mabi=lp64'
 as -v -EL -mabi=lp64 -o /tmp/ccQTdQSB.o /tmp/ccMUpatn.s
GNU assembler version 2.25 (aarch64-redhat-linux) using BFD version version 2.25-7.1.fc23
COMPILER_PATH=/usr/libexec/gcc/aarch64-redhat-linux/4.9.2/:/usr/libexec/gcc/aarch64-redhat-linux/4.9.2/:/usr/libexec/gcc/aarch64-redhat-linux/:/usr/lib/gcc/aarch64-redhat-linux/4.9.2/:/usr/lib/gcc/aarch64-redhat-linux/
LIBRARY_PATH=/usr/lib/gcc/aarch64-redhat-linux/4.9.2/:/usr/lib/gcc/aarch64-redhat-linux/4.9.2/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/usr/lib/gcc/aarch64-redhat-linux/4.9.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'conftest' '-fuse-ld=gold' '-mlittle-endian' '-mabi=lp64'
 /usr/libexec/gcc/aarch64-redhat-linux/4.9.2/collect2 -plugin /usr/libexec/gcc/aarch64-redhat-linux/4.9.2/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/aarch64-redhat-linux/4.9.2/lto-wrapper -plugin-opt=-fresolution=/tmp/ccyt2r4Q.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id --no-add-needed --eh-frame-hdr --hash-style=gnu -dynamic-linker /lib/ld-linux-aarch64.so.1 -X -EL -maarch64linux -fuse-ld=gold -o conftest /usr/lib/gcc/aarch64-redhat-linux/4.9.2/../../../../lib64/crt1.o /usr/lib/gcc/aarch64-redhat-linux/4.9.2/../../../../lib64/crti.o /usr/lib/gcc/aarch64-redhat-linux/4.9.2/crtbegin.o -L/usr/lib/gcc/aarch64-redhat-linux/4.9.2 -L/usr/lib/gcc/aarch64-redhat-linux/4.9.2/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/aarch64-redhat-linux/4.9.2/../../.. /tmp/ccQTdQSB.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/aarch64-redhat-linux/4.9.2/crtend.o /usr/lib/gcc/aarch64-redhat-linux/4.9.2/../../../../lib64/crtn.o

Comment 4 Nick Clifton 2015-04-28 09:44:21 UTC
Hi Jens,

  Is there an aarch64 machine I can log in to ?  I have been trying to reproduce the problem using a cross built toolchain, but I have not managed to make gold crash. :-(

Cheers
  Nick

Comment 5 Jens Petersen 2015-04-28 10:13:57 UTC
Nick, let me send you an email.

Comment 6 Nick Clifton 2015-04-29 13:11:43 UTC
Summary of discoveries so far:

  * Cannot reproduce the problem using a cross-built toolchain.
  * Can reproduce using a native toolchain on a Fedora 21 machine.
  * Problem exists both with rawhide binutils (based on FSF binutils 2.25) and FSF mainline development sources.
  * Problem exists only when linking with gold, not with ld.
  * A binary linked using gold running on an x86_64 host running Fedora 21 will run.

There appear to be a couple of possibilities for the cause of the problem:

  * A bug in Fedora 21 gcc means that compiling gold natively on aarch64 results in a subtly broken gold executable.

  * A bug in the gold sources is only being triggered when linking natively.

I am still investigating, but it is going to take some time.

Cheers
  Nick

Comment 7 Jens Petersen 2015-04-30 03:58:05 UTC
Thank you for looking into this.

(In reply to Nick Clifton from comment #6)
>   * Can reproduce using a native toolchain on a Fedora 21 machine.

Note that it also happens in Rawhide, which has gcc-5.0.1-0.1.fc23.aarch64.

eg http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=2972494

binutils-2.25-8.fc23 was also built with gcc-5.0.1-0.1.fc23.aarch64.

Comment 8 Nick Clifton 2015-05-01 13:40:28 UTC
Hi Guys,

> Summary of discoveries so far:
> 
>   * A binary linked using gold running on an x86_64 host running Fedora 21
> will run.

Scratch that.  The problem still exists with cross built executables.  The problem goes away however if you build *static* executables, either natively or with a cross-toolchain.  (I was mistakenly building a static version of conftest with my cross tools, which is why I thought cross-building worked).

So that at least suggests a temporary workaround - building a static version of ghc.

Meanwhile, now that I can compile test binaries locally I might be able to get a bit further investigating the real problem.

Does anybody know how to persuade ld-linux-aarch64.so.1 to tell me why it refuses to load a binary ?  All I get is a non-zero return value, but no error message of any kind.

Cheers
  Nick

Comment 9 Nick Clifton 2015-05-05 14:29:48 UTC
FYI, I have reported this bug upstream:

https://sourceware.org/bugzilla/show_bug.cgi?id=18365

Comment 10 Nick Clifton 2015-05-06 09:44:17 UTC
Created attachment 1022542 [details]
Working dynamic conftest executable

Hi Guys,

  Right - I am officially out of my depth here.  Gold *is* creating working dynamic executables.  Just not ones that will work on mustang-02.  If you read the FSF bugzilla PR you will see that Han Shenan was able to run the conftest executable created by gold on mustang-02, and he was able to link and run his own executable on his machine.  But when I try to run that same executable on mustang-02 it fails.  So there must be something about our machine that is different from his, something that prevents dynamic executables from working.

  I do not know enough about loaders to find out what is going wrong.  We need a glibc expert to tell us why ld.so does not like the conftest executables, and then maybe we can find a solution.

Cheers
  Nick

Comment 11 Jakub Jelinek 2015-05-06 09:47:58 UTC
Just a wild guess, the pagesize might be different (or size of virtual address space, but the latter hopefully shouldn't matter).

Comment 12 Nick Clifton 2015-05-06 10:09:24 UTC
Hi Jakub,

> Just a wild guess, the pagesize might be different

Is there some way to test this ?  

The working ld-produced dynamic binary and the non-working gold-produced dynamic binary both have an alignment of 0x1000 for the LOAD segments.

What do we know about the pagesize requirement of the mustang boards ?

Cheers
  Nick

PS.  I thought that it might be an executable stack problem, since Han's conftest binary has a GNU_STACK segment that has RWE flags.  But the non-working version produced locally on mustang-02 only has RW flags, so that is not it. :-(

Comment 13 Jakub Jelinek 2015-05-06 10:19:37 UTC
0x1000 PT_LOAD alignment on an architecture that allows 4KB and 64KB page sizes sounds just wrong.
See https://www.kernel.org/doc/Documentation/arm64/memory.txt
Easy way to test would be
getconf PAGESIZE
I'd say.

elfnn-aarch64.c:#define ELF_MAXPAGESIZE			0x10000
elfnn-aarch64.c:#define ELF_MINPAGESIZE			0x1000
elfnn-aarch64.c:#define ELF_COMMONPAGESIZE		0x1000

looks good to me (though I hope that for Fedora/RHEL where 64KB page size is used we patch ELF_COMMONPAGESIZE to 64KB).

Comment 14 Jens Petersen 2015-05-07 04:26:42 UTC
(In reply to Nick Clifton from comment #8)
> The problem still exists with cross built executables.  The
> problem goes away however if you build *static* executables, either natively
> or with a cross-toolchain.  (I was mistakenly building a static version of
> conftest with my cross tools, which is why I thought cross-building worked).

Ah, I forgot to comment about this:

> So that at least suggests a temporary workaround - building a static version
> of ghc.

That's right - I am actually building ghc on aarch64 with Haskell static linking to workaround a problem with stdout getting lost from
dynamically linked executables.

(In reply to Nick Clifton from comment #10)
>   Right - I am officially out of my depth here.  Gold *is* creating working
> dynamic executables.  Just not ones that will work on mustang-02.  If you
> read the FSF bugzilla PR you will see that Han Shenan was able to run the
> conftest executable created by gold on mustang-02, and he was able to link
> and run his own executable on his machine.  But when I try to run that same
> executable on mustang-02 it fails.  So there must be something about our
> machine that is different from his, something that prevents dynamic
> executables from working.

Okay this also agrees with my ghc friend who is running Debian on aarch64
and hasn't seen this problem either: so I agree that this seems to be
Fedora specific.

Comment 15 Jens Petersen 2015-05-22 05:53:38 UTC
Any more headway with this?

Comment 16 Nick Clifton 2015-06-10 19:41:04 UTC
Hi Jens,

  This problem *might* be fixed by binutils-2.25-10.fc23 and/or binutils-2.25-8.fc22.  Please give one of them a try and let me know if gold really is working now.

Cheers
  Nick

Comment 17 Jens Petersen 2015-06-11 07:54:26 UTC
Yes, I tested binutils-2.25-10.fc23 with my ghc-7.10.1.20150511-1.fc21.src.rpm
and it went through configure file.  So looks good to me.

Comment 18 Jens Petersen 2015-06-11 10:12:31 UTC
For the record the scratch build:

http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3032351

(ignore the final filelist errors that is due to ghc-rpm-macros
needing tweaks for ghc-7.10.)

Comment 19 Jens Petersen 2015-06-15 14:26:37 UTC
It looks good to me still: also fixes bug 1195231.

Can binutils-2.25-8.fc22 be pushed to updates-testing?

Comment 20 Fedora Update System 2015-06-15 15:26:47 UTC
binutils-2.25-8.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/binutils-2.25-8.fc22

Comment 21 Fedora Update System 2015-06-18 13:21:10 UTC
Package binutils-2.25-8.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing binutils-2.25-8.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-10051/binutils-2.25-8.fc22
then log in and leave karma (feedback).

Comment 22 Fedora Update System 2015-06-21 00:17:57 UTC
binutils-2.25-8.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.