http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55308
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> 2013-02-25 13:29:36 UTC --- > --- Comment #8 from N8GCBP7SHNBTI79GINADGKJPRTLOCO2A at cmx dot ietfng.org > 2013-02-23 03:13:27 UTC --- > If I do not remove the -32 from configure and do a straight build out of the > ports tree, I see this in my gcc/config.log: > > configure:23478: checking assembler for thread-local storage support > configure:23491: /usr/local/bin/as -32 --fatal-warnings -o conftest.o > conftest.s >&5 > Assembler messages: > Fatal error: selected target format 'elf32-sparc-freebsd' unknown > configure:23494: $? = 1 > configure: failed program was > > .section ".tdata","awT",@progbits > foo: .long 25 > .text > sethi %tgd_hi22(foo), %o0 > > This appears to be the root cause of everything going south with the error > Anton > gave at the start of this thread, as xgcc is built without support for TLS, as > I > said in comment 2. I am at a loss to explain the error in comment 5, except > to > suggest that possibly some of the wrong lines were mutated (I did not check > carefully; the actual patch I am using is available at > https://github.com/nwf/nwf-patches/blob/master/freebsd-ports/gcc48-patch-sparc64-tls-fix > and should apply with no complaints; I simply place it in my ports tree as > /usr/ports/lang/gcc48/files/patch-sparc64-tls-fix and let the make magic do > its > magic.) I'd ignore that error for now, since it is certainly not related to TLS support. The same goes for the apparent attempt to link libstdc++.so.6 into libgcc_s.so.1 in the Description. > "/usr/local/bin/as --version" says > > GNU assembler (GNU Binutils) 2.23.1 > Copyright 2012 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or later. > This program has absolutely no warranty. > This assembler was configured for a target of `sparc64-portbld-freebsd9.1'. Good you mention which assembler is actually used, i.e. not the bundled FreeBSD as, but current binutils gas. Any additional patches to that? > And unhelpfully its --target-help does indeed suggest that it knows about -32, > but even invoking just "as -32" yields the "selected target format unknown" > message above. > > "/usr/local/bin/objdump -H" says, among many other things, > > /usr/local/bin/objdump: supported targets: elf64-sparc-freebsd elf64-sparc > elf32-sparc a.out-sunos-big elf64-little elf64-big elf32-little elf32-big > plugin srec symbolsrec verilog tekhex binary ihex > /usr/local/bin/objdump: supported architectures: sparc sparc:sparclet > sparc:sparclite sparc:v8plus sparc:v8plusa sparc:sparclite_le sparc:v9 > sparc:v9a sparc:v8plusb sparc:v9b plugin > > which may reveal something: there is no elf32-sparc-freebsd on that list... > and > indeed, looking inside the binutils sources, I see that there is special > handling in bfd/elf64-sparc.c for FreeBSD that is absent in bfd/elf32-sparc.c. > The story appears to be the same in the in-FreeBSD version of binutils in > /usr/src. In fact, the only occurrence of "elf32-sparc-freebsd" at all > binutils > is in gas/config/tc-sparc.h, which seems like something of a bug in its own > right. (Which I have filed, at > http://sourceware.org/bugzilla/show_bug.cgi?id=15178 ) > > That said, all the binaries on my system (which is, as far as I know, > relatively > stock FreeBSD 9-STABLE) are ELF 64, not ELF 32, and so, fundamentally, I don't > understand why configure is testing for the ability to build a 32 bit binary > rather than the assembler's default. Possibly some systems require that; > binutils on FreeBSD on sparc appears to require its negation. The question is not if the FreeBSD/SPARC binaries are SPARC64, but if the kernel is able to execute 32-bit binaries and 32-bit runtime libs exist for the system. If not, than indeed there is no point in building a multilib-capable compiler. I'd suggest configuring gcc with --disable-multilib in that case. > Does that help shed any light on the situation? Anything I've overlooked? It does indeed. I've now had a look at the TLS testcase and was originally inclined to claim that the -32 flag is there in error, but unfortunately this is not true: assembling it with gas 2.23.1 with either -32, -64, or no flag at all produces an object file without error or warning. OTOH, if I try the same with Sun as (and the corresponding .section directive), I get an error if assembling as 64-bit code: > as -xarch=v9 -o tls.o-64 tls.s as: "tls.s", line 17: error: unknown "%"-symbol as: "tls.s", line 17: error: missing '(' as: "tls.s", line 17: error: statement syntax as: "tls.s", line 18: warning: detect global register use not covered .register pseudo-op as: "tls.s", line 21: warning: detect global register use not covered .register pseudo-op The op on line 17 is ld [%l7 + %o3], %o2, %tie_ld(foo) and indeed %tie_ld is 32-bit only. gas just fails to diagnose that, while as does. I'd claim this is a bug in gas, and a proper fix of the configure.ac statement for 64-bit-only sparc targets is a bit more involved than just omitting the -32. I'll leave that to the sparc maintainers. Rainer
