Bug 195934 - clang350-import branch not working on sparc64
Summary: clang350-import branch not working on sparc64
Status: Closed Overcome By Events
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 10.1-RELEASE
Hardware: sparc64 Any
: --- Affects Some People
Assignee: Dimitry Andric
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-12-13 05:58 UTC by craig001
Modified: 2018-03-20 00:30 UTC (History)
4 users (show)

See Also:


Attachments
make toolchain script session (365.21 KB, application/gzip)
2014-12-13 05:58 UTC, craig001
no flags Details
make buildworld script session (365.18 KB, application/gzip)
2014-12-13 05:59 UTC, craig001
no flags Details
make buildkernel script session (2.23 KB, application/gzip)
2014-12-13 06:01 UTC, craig001
no flags Details
failed make buildworld session (404.46 KB, application/gzip)
2015-07-20 08:27 UTC, craig001
no flags Details
failed make buildworld gcc48 session (358.76 KB, application/x-gzip)
2015-08-06 07:58 UTC, craig001
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description craig001 2014-12-13 05:58:35 UTC
Created attachment 150528 [details]
make toolchain script session

I cannot get clang350-import src to build on a 10.1-RELEASE sparc64 with clang34 and libc++ compiled.

I have attached the script sessions to this bug report.

Summary;
make toolchain   -- failed
make buildworld  -- failed

I have also tried to build clang/llvm out of tree using sources from their svn server.  I can get clang (3.6.0 trunk) built but it then fails to build kernel.

make buildkernel -- failed

Kind Regards

Craig Butler
Comment 1 craig001 2014-12-13 05:59:31 UTC
Created attachment 150529 [details]
make buildworld script session
Comment 2 craig001 2014-12-13 06:01:54 UTC
Created attachment 150530 [details]
make buildkernel script session
Comment 3 craig001 2014-12-14 03:28:01 UTC
managed to buildkernel with out off tree clang/llvm, but still showing same issue when trying to boot it;

lom>poweron                       
lom>       
LOM event: +8h36m11s host power on
ΓΌ                                 
Sun Fire V120 (UltraSPARC-IIe 648MHz), No Keyboard
OpenBoot 4.0, 1024 MB memory installed, Serial #53822332.
Ethernet address 0:3:ba:35:43:7c, Host ID: 8335437c.



Boot device: disk  File and args:                                     
 
>> FreeBSD/sparc64 boot block
   Boot path:   /pci@1f,0/pci@1/scsi@8/disk@0,0:a
   Boot loader: /boot/loader
Consoles: Open Firmware console  

FreeBSD/sparc64 bootstrap loader, Revision 1.0
(root@bulldog.lerwick.hopto.org, Mon Dec  1 18:28:07 GMT 2014)
bootpath="/pci@1f,0/pci@1/scsi@8/disk@0,0:a"
Loading /boot/defaults/loader.conf 
/boot/kernel/kernel data=0xceda20+0x20fb10 syms=[0x8+0xc11e8+0x8+0xb8b70]
/boot/kernel/geom_mirror.ko text=0x40078 data=0x500+0x18 syms=[0x8+0x1428+0x8+0xed0]

Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...               
jumping to kernel entry at 0xc00a8000.
Data Access Exception
ok
Comment 4 John Marino freebsd_committer 2015-01-25 18:26:49 UTC
Move this PR to base (it's not a ports problem)
Comment 5 Christian Brueffer freebsd_committer 2015-07-13 15:50:21 UTC
Adding dim@; is this still an issue with the recent clang versions?
Comment 6 Dimitry Andric freebsd_committer 2015-07-13 17:36:31 UTC
(In reply to Christian Brueffer from comment #5)
> Adding dim@; is this still an issue with the recent clang versions?

I don't think much changed: upstream has had very little activity in the Sparc backend, and we have never found a good way to get to a bootable kernel.  Last time I tried, on one of the now-defunct reference sparc64 machines, at least world to built OK, and it also appeared to run OK, in light testing.

That said, if the original submitter would like to try with a fairly recent clang trunk snapshot, please use the projects/clang-trunk branch instead.
Comment 7 craig001 2015-07-13 19:26:23 UTC
Yes, will co.

Am out the office at the moment, but should be able to get on this in a couple of days.

Report back shortly.

Thanks folks...
Comment 8 craig001 2015-07-19 20:55:18 UTC
checkout svn://svn.freebsd.org/base/projects/clang-trunk
Revision: 285701

both buildworld and toolchain are falling over with;
cc1plus: error: unrecognized command line option "-std=c++11"

root@stinger:/home/craig # uname -a
FreeBSD stinger.bsdtec.net 10.1-RELEASE FreeBSD 10.1-RELEASE #0: Tue Dec  2 08:26:19 GMT 2014     root@bulldog.lerwick.hopto.org:/usr/obj/usr/src/sys/GENERIC  sparc64

root@stinger:/home/craig # gcc -v
Using built-in specs.
Target: sparc64-undermydesk-freebsd
Configured with: FreeBSD/sparc64 system compiler
Thread model: posix
gcc version 4.2.1 20070831 patched [FreeBSD]

I'll try building with clang from 10.1......
Comment 9 craig001 2015-07-20 08:26:01 UTC
failing with clang also;

clang  -O2 -pipe   -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/sparc64 -DNLS  -I/usr/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime  -I/usr/src/lib/libc/locale -I/usr/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -fno-dwarf2-cfi-asm -I/usr/src/lib/libutil -I/usr/src/lib/msun/sparc64 -I/usr/src/lib/msun/src -c /usr/src/lib/libc/sparc64/fpu/fpu.c -o fpu.o
In file included from /usr/src/lib/libc/sparc64/fpu/fpu.c:72:
/usr/src/lib/libc/../../include/signal.h:84:60: error: expected function body
      after function declarator
int     sigwait(const sigset_t * __restrict, int * __restrict) __nonnull_all;
                                                               ^
In file included from /usr/src/lib/libc/sparc64/fpu/fpu.c:76:
/usr/src/lib/libc/../../include/stdlib.h:90:44: error: expected function body
      after function declarator
void    *calloc(size_t, size_t) __malloc_like __result_use_check
                                              ^
/usr/src/lib/libc/../../include/stdlib.h:98:36: error: expected function body
      after function declarator
void    *malloc(size_t) __malloc_like __result_use_check __alloc_size(1);
                                      ^
/usr/src/lib/libc/../../include/stdlib.h:105:31: error: expected function body
      after function declarator
void    *realloc(void *, size_t) __result_use_check __alloc_size(2);
                                 ^
/usr/src/lib/libc/../../include/stdlib.h:159:52: error: expected function body
      after function declarator
void *  aligned_alloc(size_t, size_t) __malloc_like __alloc_align(1)
                                                    ^
/usr/src/lib/libc/../../include/stdlib.h:175:59: error: expected function body
      after function declarator
int      posix_memalign(void **, size_t, size_t) __nonnull(1) __alloc_align(2)
                                                              ^
/usr/src/lib/libc/../../include/stdlib.h:307:44: error: expected function body
      after function declarator
void    *reallocarray(void *, size_t, size_t) __result_use_check __alloc_size(2)
                                              ^
/usr/src/lib/libc/../../include/stdlib.h:309:32: error: expected function body
      after function declarator
void    *reallocf(void *, size_t) __alloc_size(2);
                                  ^
In file included from /usr/src/lib/libc/sparc64/fpu/fpu.c:77:
/usr/src/lib/libc/../../include/unistd.h:330:45: error: expected function body
      after function declarator
int      execl(const char *, const char *, ...) __sentinel;
                                                ^
/usr/src/lib/libc/../../include/unistd.h:332:46: error: expected function body
      after function declarator
int      execlp(const char *, const char *, ...) __sentinel;
                                                 ^
10 errors generated.
*** Error code 1

craig@stinger:~ % clang --version
FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512
Target: sparc64-unknown-freebsd10.1
Thread model: posix

please advise :)
Comment 10 craig001 2015-07-20 08:27:39 UTC
Created attachment 159014 [details]
failed make buildworld session
Comment 11 Dimitry Andric freebsd_committer 2015-07-22 20:21:59 UTC
(In reply to craig001 from comment #8)
> checkout svn://svn.freebsd.org/base/projects/clang-trunk
> Revision: 285701
> 
> both buildworld and toolchain are falling over with;
> cc1plus: error: unrecognized command line option "-std=c++11"

Yes, this is expected.  You cannot build clang 3.5.0 or higher with base gcc, you need gcc 4.8 or higher, or clang 3.2 or higher, and a C++11 compatible C++ library (e.g. libc++).


(In reply to craig001 from comment #9)
> failing with clang also;
> 
> clang  -O2 -pipe   -I/usr/src/lib/libc/include
> -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/sparc64 -DNLS 
> -I/usr/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE
> -I/usr/src/lib/libc/../../contrib/gdtoa
> -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6
> -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE
> -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd
> -I/usr/src/lib/libc/../../contrib/jemalloc/include
> -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime
> -I/usr/src/lib/libc/locale -I/usr/src/lib/libc/sparc64/fpu -DBROKEN_DES
> -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING
> -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror
> -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
> -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare
> -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
> -Wno-enum-conversion -Wno-switch -Wno-switch-enum
> -Wno-knr-promoted-parameter -Qunused-arguments -fno-dwarf2-cfi-asm
> -I/usr/src/lib/libutil -I/usr/src/lib/msun/sparc64 -I/usr/src/lib/msun/src
> -c /usr/src/lib/libc/sparc64/fpu/fpu.c -o fpu.o
> In file included from /usr/src/lib/libc/sparc64/fpu/fpu.c:72:
> /usr/src/lib/libc/../../include/signal.h:84:60: error: expected function body
>       after function declarator
> int     sigwait(const sigset_t * __restrict, int * __restrict) __nonnull_all;
>                                                                ^

Hm, this looks like some problem with your system headers, maybe?  These __nonnull attributes were introduced recently, maybe you have a half-finished installation, or checkout?

I'm currently doing a buildworld with TARGET=sparc64, and it's already gotten to the cross-tools part.  When it gets to compiling libc, I will see if I get the same errors as you saw.
Comment 12 craig001 2015-07-22 21:04:11 UTC
Hello Dimitry

My stinger server is a 10.1-RELEASE sparc64, with the base clang compiled (clang is not defacto on sparc64)

The original /usr/src and /usr/obj where renamed, and I created an empty /usr/obj and svnlite checkout of projects/clang-trunk to /usr/src as requested.

I can install a later RELEASE (maybe one of the 10.2-RC ??) or maybe a CURRENT if desired.
Comment 13 Dimitry Andric freebsd_committer 2015-07-22 21:29:07 UTC
For me it also error'd out, but at compiler-rt, which complaints about invalid assembler mnemonics:

--- divsi3.o ---
contrib/compiler-rt/lib/builtins/sparc64/divsi3.S:52:2: error:
 too few operands for instruction
 b divide
 ^
contrib/compiler-rt/lib/builtins/sparc64/divsi3.S:60:2: error: invalid instruction mnemonic
 tst %o1
 ^

and a lot more like these.  I don't think the integrated assembler is very usable for sparc, so I'll try again with -no-integrated-as.
Comment 14 Dimitry Andric freebsd_committer 2015-07-22 21:33:06 UTC
Ok, so even with -no-integrated-as, it still dies, because our copy of GNU as does not grok .cfi directives:

--- cddl/lib__L ---
/tmp/bplist-6222cb.s: Assembler messages:
/tmp/bplist-6222cb.s:1330: Error: unknown pseudo-op: `.cfi_sections'
cc: error: assembler command failed with exit code 1 (use -v to see invocation)
*** [bplist.So] Error code 1

Strangely enough, this is even when using the -fno-dwarf2-cfi-asm option, and it only happens when compiling certain files.  I have no clue at this point what is going wrong, and unfortunately I am out of time for the moment.

If anybody else with sparc knowledge can have a try, please do so.
Comment 15 Dimitry Andric freebsd_committer 2015-07-22 21:49:46 UTC
It actually helped to disable the -g flag used while building libzpool.  I think compiling with debug info is out of the question for now...

The diff I'm using now is this:

Index: cddl/lib/libzpool/Makefile
===================================================================
--- cddl/lib/libzpool/Makefile  (revision 285803)
+++ cddl/lib/libzpool/Makefile  (working copy)
@@ -68,6 +68,7 @@
 # Since there are many asserts in this library, it makes no sense to compile
 # it without debugging.

-CFLAGS+=       -g -DDEBUG=1
+#CFLAGS+=      -g
+CFLAGS+=       -DDEBUG=1

 .include <bsd.lib.mk>
Index: share/mk/bsd.sys.mk
===================================================================
--- share/mk/bsd.sys.mk (revision 285803)
+++ share/mk/bsd.sys.mk (working copy)
@@ -137,7 +137,7 @@
 CFLAGS.clang+=  -Qunused-arguments
 .if ${MACHINE_CPUARCH} == "sparc64"
 # Don't emit .cfi directives, since we must use GNU as on sparc64, for now.
-CFLAGS.clang+=  -fno-dwarf2-cfi-asm
+CFLAGS.clang+=  -fno-dwarf2-cfi-asm -no-integrated-as
 .endif # SPARC64
 # The libc++ headers use c++11 extensions.  These are normally silenced because
 # they are treated as system headers, but we explicitly disable that warning

It's still building, I'll see tomorrow how it has fared.
Comment 16 craig001 2015-08-06 07:57:29 UTC
also binning out with pages of errors with gcc48

/usr/local/bin/gcc48  -O2 -pipe   -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/sparc64 -DNLS  -I/usr/src/lib/libc/sparc64/sys -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -I/usr/src/lib/libc/../../contrib/libc-vis -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../libmd -I/usr/src/lib/libc/../../contrib/jemalloc/include -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime  -I/usr/src/lib/libc/locale -I/usr/src/lib/libc/sparc64/fpu -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign   -I/usr/src/lib/libutil -I/usr/src/lib/msun/sparc64 -I/usr/src/lib/msun/src -c /usr/src/lib/libc/sparc64/fpu/fpu.c -o fpu.o
In file included from /usr/src/lib/libc/sparc64/fpu/fpu.c:72:0:
/usr/src/lib/libc/../../include/signal.h: In function 'sigwait':
/usr/src/lib/libc/../../include/signal.h:84:60: error: expected declaration specifiers before '__nonnull_all'
 int sigwait(const sigset_t * __restrict, int * __restrict) __nonnull_all;

script session to follow
Comment 17 craig001 2015-08-06 07:58:56 UTC
Created attachment 159605 [details]
failed make buildworld gcc48 session
Comment 18 Dimitry Andric freebsd_committer 2015-08-06 17:35:19 UTC
(In reply to craig001 from comment #16)
> also binning out with pages of errors with gcc48
> /usr/src/lib/libc/../../include/signal.h: In function 'sigwait':
> /usr/src/lib/libc/../../include/signal.h:84:60: error: expected declaration
> specifiers before '__nonnull_all'
>  int sigwait(const sigset_t * __restrict, int * __restrict) __nonnull_all;

I'm not sure what is going wrong here, but it looks like its using an incorrect version of sys/cdefs.h, which is where the __nonnull_all macro is defined.  Is your source tree completely up to date?
Comment 19 craig001 2015-08-07 21:25:53 UTC
Hello Dimitry

I'll try and repeat the process on a vanilla machine this weekend (to see if it is repeatable)

1) 10.1-RELEASE sparc64 vanilla install
2) 10.1-RELEASE src
3) compile world with base gcc to include clang 3.4.1, install world
4) compile gcc48
5) mv src and obj to .old
6) checkout clang-trunk as src, create obj dir
7) try makeworld using clang 3.4.1
8) try makeworld using gcc48

report back shortly...
Comment 20 craig001 2015-08-10 19:58:59 UTC
quick update...

natively built and installed clang and libc++ on 10.1-RELEASE, checked out clang-trunk and trying to build with clang

getting clobbered by fatal error: 'sys/capsicum.h' file not found

quick google lead me to;
make buildworld SRCCONF=/dev/null __MAKE_CONF=/dev/null

and can get a successful buildworld.  Not sure what it means yet :/

gcc48 still building
Comment 21 Edina Clark 2017-02-17 08:05:25 UTC
MARKED AS SPAM
Comment 22 craig001 2018-03-20 00:30:38 UTC
old school, still and issue... sparc64 is probably dead and not getting any clang help