Re: HEADS UP: sparc64 backend for llvm/clang imported
On Wed, Aug 19, 2015 at 04:19:03PM -0400, Kurt Lidl wrote: Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100: In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. If you have any sparc64 hardware, and are not afraid to encounter rough edges, please try out building and running your system with clang. To do so, update to at least r262613, and enable the following options in e.g. src.conf, or in your build environment: WITH_CLANG=y WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y (optional) Alternatively, if you would rather keep gcc as /usr/bin/cc for the moment, build world using just WITH_CLANG, enabling clang to be built (by gcc) and installed. After installworld, you can then set CC=clang, CXX=clang++ and CPP=clang-cpp for building another world. For building the sparc64 kernel, there is one open issue left, which is that sys/sparc64/include/pcpu.h uses global register variables, and this is not supported by clang. A preliminary patch for this is attached, but it may or may not blow up your system, please beware! The patch changes the pcpu and curpcb global register variables into inline functions, similar to what is done on other architectures. However, the current approach is not optimal, and the emitted code is slightly different from what gcc outputs. Any improvements to this patch are greatly appreciated! Last but not least, thanks go out to Roman Divacky for his work with llvm/clang upstream in getting the sparc64 backend into shape. Ok, I have a new pcpu patch to try. I have only compile tested it. It is available here: https://www.funkthat.com/~jmg/sparc64.pcpu.patch I've also attached it. Craig, do you mind testing it? This patch also removes curpcb as it appears to not be used by any sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up curpcb used in machdep code, and no references to it under sparc64. This is not a proper solution in that it can mean counters/stats can be copied/moved to other cpus overwriting the previous values if a race happens... We use PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's no worse than what we were previously using.. Until we get a proper fix which involves mapping all the cpu's PCPU data on all CPUs, this will have to sufice.. This patch is based upon, I believe, a patch from Marius and possibly modified by rdivacky. Thanks for testing.. The above message was posted a while ago, and I decided that I would give the patch a test run on a spare sparc that I have, now that the instability problem with multiprocessor sparc64 machines has been resolved. So, I have an up-to-date stable/10 V240 (2x1.5Ghz cpus, 8GB of memory), running a completely stock r286861. That all seems to work just fine. I applied the patch referenced in the email: https://www.funkthat.com/~jmg/sparc64.pcpu.patch (it applied cleanly), and then rebuilt the kernel on the machine, using the stock gcc 4.2.1 compiler. When rebooting with that kernel, the machine panics pretty early in the boot: FreeBSD 10.2-STABLE #3 r286861M: Wed Aug 19 14:28:45 EDT 2015 l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 8589934592 (8192 MB) avail memory = 8379719680 (7991 MB) cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random device not loaded; using insecure entropy panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc05750e0 at panic+0x20 #1 0xc08db9f8 at trap+0x558 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout shutting down CPUs. So, the patch to get rid of the pcpu usage (as a prereq to poking at the clang compiler issues) does not work properly. As I pointed out when that patch was posted, the approach taken by it assumes a CPU can access foreign PCPU data, which currently isn't true on sparc64. So the patch is at least incomplete but also may have further issues. Such a patch is no longer a prerequisite for compiling a sparc64 kernel with clang, though, as clang meanwhile has been told to grok at least the global registers used by the PCPU code. Besides some default options like the choice of code model not being appropriate for FreeBSD, clang-compiled loader and kernel don't work due to two major problems present in clang up to at least version 3.6.0: a) it uses a different stack layout than GCC so any unwinding code fails and b) it produces broken
Re: HEADS UP: sparc64 backend for llvm/clang imported
On Wed, Aug 26, 2015 at 11:14:51PM +0200, Marius Strobl wrote: On Wed, Aug 19, 2015 at 04:19:03PM -0400, Kurt Lidl wrote: Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100: In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. If you have any sparc64 hardware, and are not afraid to encounter rough edges, please try out building and running your system with clang. To do so, update to at least r262613, and enable the following options in e.g. src.conf, or in your build environment: WITH_CLANG=y WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y (optional) Alternatively, if you would rather keep gcc as /usr/bin/cc for the moment, build world using just WITH_CLANG, enabling clang to be built (by gcc) and installed. After installworld, you can then set CC=clang, CXX=clang++ and CPP=clang-cpp for building another world. For building the sparc64 kernel, there is one open issue left, which is that sys/sparc64/include/pcpu.h uses global register variables, and this is not supported by clang. A preliminary patch for this is attached, but it may or may not blow up your system, please beware! The patch changes the pcpu and curpcb global register variables into inline functions, similar to what is done on other architectures. However, the current approach is not optimal, and the emitted code is slightly different from what gcc outputs. Any improvements to this patch are greatly appreciated! Last but not least, thanks go out to Roman Divacky for his work with llvm/clang upstream in getting the sparc64 backend into shape. Ok, I have a new pcpu patch to try. I have only compile tested it. It is available here: https://www.funkthat.com/~jmg/sparc64.pcpu.patch I've also attached it. Craig, do you mind testing it? This patch also removes curpcb as it appears to not be used by any sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up curpcb used in machdep code, and no references to it under sparc64. This is not a proper solution in that it can mean counters/stats can be copied/moved to other cpus overwriting the previous values if a race happens... We use PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's no worse than what we were previously using.. Until we get a proper fix which involves mapping all the cpu's PCPU data on all CPUs, this will have to sufice.. This patch is based upon, I believe, a patch from Marius and possibly modified by rdivacky. Thanks for testing.. The above message was posted a while ago, and I decided that I would give the patch a test run on a spare sparc that I have, now that the instability problem with multiprocessor sparc64 machines has been resolved. So, I have an up-to-date stable/10 V240 (2x1.5Ghz cpus, 8GB of memory), running a completely stock r286861. That all seems to work just fine. I applied the patch referenced in the email: https://www.funkthat.com/~jmg/sparc64.pcpu.patch (it applied cleanly), and then rebuilt the kernel on the machine, using the stock gcc 4.2.1 compiler. When rebooting with that kernel, the machine panics pretty early in the boot: FreeBSD 10.2-STABLE #3 r286861M: Wed Aug 19 14:28:45 EDT 2015 l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 8589934592 (8192 MB) avail memory = 8379719680 (7991 MB) cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random device not loaded; using insecure entropy panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc05750e0 at panic+0x20 #1 0xc08db9f8 at trap+0x558 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout shutting down CPUs. So, the patch to get rid of the pcpu usage (as a prereq to poking at the clang compiler issues) does not work properly. As I pointed out when that patch was posted, the approach taken by it assumes a CPU can access foreign PCPU data, which currently isn't true on sparc64. So the patch is at least incomplete but also may have further issues. Such a patch is no longer a prerequisite for compiling a sparc64 kernel with clang, though, as clang meanwhile has been told to grok at least the global registers used by the PCPU code. Besides some default options like the choice of code model not being appropriate for FreeBSD, clang-compiled loader and kernel don't
Re: HEADS UP: sparc64 backend for llvm/clang imported
Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100: In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. If you have any sparc64 hardware, and are not afraid to encounter rough edges, please try out building and running your system with clang. To do so, update to at least r262613, and enable the following options in e.g. src.conf, or in your build environment: WITH_CLANG=y WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y (optional) Alternatively, if you would rather keep gcc as /usr/bin/cc for the moment, build world using just WITH_CLANG, enabling clang to be built (by gcc) and installed. After installworld, you can then set CC=clang, CXX=clang++ and CPP=clang-cpp for building another world. For building the sparc64 kernel, there is one open issue left, which is that sys/sparc64/include/pcpu.h uses global register variables, and this is not supported by clang. A preliminary patch for this is attached, but it may or may not blow up your system, please beware! The patch changes the pcpu and curpcb global register variables into inline functions, similar to what is done on other architectures. However, the current approach is not optimal, and the emitted code is slightly different from what gcc outputs. Any improvements to this patch are greatly appreciated! Last but not least, thanks go out to Roman Divacky for his work with llvm/clang upstream in getting the sparc64 backend into shape. Ok, I have a new pcpu patch to try. I have only compile tested it. It is available here: https://www.funkthat.com/~jmg/sparc64.pcpu.patch I've also attached it. Craig, do you mind testing it? This patch also removes curpcb as it appears to not be used by any sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up curpcb used in machdep code, and no references to it under sparc64. This is not a proper solution in that it can mean counters/stats can be copied/moved to other cpus overwriting the previous values if a race happens... We use PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's no worse than what we were previously using.. Until we get a proper fix which involves mapping all the cpu's PCPU data on all CPUs, this will have to sufice.. This patch is based upon, I believe, a patch from Marius and possibly modified by rdivacky. Thanks for testing.. The above message was posted a while ago, and I decided that I would give the patch a test run on a spare sparc that I have, now that the instability problem with multiprocessor sparc64 machines has been resolved. So, I have an up-to-date stable/10 V240 (2x1.5Ghz cpus, 8GB of memory), running a completely stock r286861. That all seems to work just fine. I applied the patch referenced in the email: https://www.funkthat.com/~jmg/sparc64.pcpu.patch (it applied cleanly), and then rebuilt the kernel on the machine, using the stock gcc 4.2.1 compiler. When rebooting with that kernel, the machine panics pretty early in the boot: FreeBSD 10.2-STABLE #3 r286861M: Wed Aug 19 14:28:45 EDT 2015 l...@spork.pix.net:/usr/obj/usr/src/sys/GENERIC sparc64 gcc version 4.2.1 20070831 patched [FreeBSD] real memory = 8589934592 (8192 MB) avail memory = 8379719680 (7991 MB) cpu0: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) cpu1: Sun Microsystems UltraSparc-IIIi Processor (1503.00 MHz CPU) FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs random device not loaded; using insecure entropy panic: trap: illegal instruction (kernel) cpuid = 0 KDB: stack backtrace: #0 0xc05750e0 at panic+0x20 #1 0xc08db9f8 at trap+0x558 Uptime: 1s Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... timeout shutting down CPUs. So, the patch to get rid of the pcpu usage (as a prereq to poking at the clang compiler issues) does not work properly. -Kurt ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: sparc64 backend for llvm/clang imported
Florian Smeets wrote this message on Sat, Mar 01, 2014 at 16:28 +0100:
On 01/03/14 02:16, John-Mark Gurney wrote:
Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100:
For building the sparc64 kernel, there is one open issue left, which is
that sys/sparc64/include/pcpu.h uses global register variables, and this
is not supported by clang. A preliminary patch for this is attached,
but it may or may not blow up your system, please beware!
The patch changes the pcpu and curpcb global register variables into
inline functions, similar to what is done on other architectures.
However, the current approach is not optimal, and the emitted code is
slightly different from what gcc outputs. Any improvements to this
patch are greatly appreciated!
Last but not least, thanks go out to Roman Divacky for his work with
llvm/clang upstream in getting the sparc64 backend into shape.
Ok, I have a new pcpu patch to try. I have only compile tested it.
It is available here:
https://www.funkthat.com/~jmg/sparc64.pcpu.patch
I've also attached it.
Craig, do you mind testing it?
My machine doesn't boot with this patch.
OK boot -v
Booting...
jumping to kernel entry at 0xc0088000.
OF_panic: sparc64_init: cannot find boot CPU node
Program terminated
{1} ok
I'm now going to try the version that dim sent.
Does it boot w/o the patch? Is this a clang built loader/kernel or
a gcc built loader/kernel that you tried the patch on?
From a quick look at the code, it doesn't look like my patch would
have effected this part of the kernel...
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: sparc64 backend for llvm/clang imported
- Original Message -
From: John-Mark Gurney j...@funkthat.com
To: Florian Smeets f...@smeets.im
Cc: Dimitry Andric d...@freebsd.org, Craig Butler
craig...@lerwick.hopto.org, freebsd-current@freebsd.org,
freebsd-spar...@freebsd.org, rdiva...@freebsd.org
Sent: Saturday, 1 March, 2014 7:51:58 PM
Subject: Re: HEADS UP: sparc64 backend for llvm/clang imported
Florian Smeets wrote this message on Sat, Mar 01, 2014 at 16:28
+0100:
On 01/03/14 02:16, John-Mark Gurney wrote:
Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22
+0100:
For building the sparc64 kernel, there is one open issue left,
which is
that sys/sparc64/include/pcpu.h uses global register variables,
and this
is not supported by clang. A preliminary patch for this is
attached,
but it may or may not blow up your system, please beware!
The patch changes the pcpu and curpcb global register variables
into
inline functions, similar to what is done on other
architectures.
However, the current approach is not optimal, and the emitted
code is
slightly different from what gcc outputs. Any improvements to
this
patch are greatly appreciated!
Last but not least, thanks go out to Roman Divacky for his work
with
llvm/clang upstream in getting the sparc64 backend into shape.
Ok, I have a new pcpu patch to try. I have only compile tested
it.
It is available here:
https://www.funkthat.com/~jmg/sparc64.pcpu.patch
I've also attached it.
Craig, do you mind testing it?
My machine doesn't boot with this patch.
OK boot -v
Booting...
jumping to kernel entry at 0xc0088000.
OF_panic: sparc64_init: cannot find boot CPU node
Program terminated
{1} ok
I'm now going to try the version that dim sent.
Does it boot w/o the patch? Is this a clang built loader/kernel or
a gcc built loader/kernel that you tried the patch on?
From a quick look at the code, it doesn't look like my patch would
have effected this part of the kernel...
--
John-Mark GurneyVoice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
It's not working here either.. Native base gcc compiled 10-RELEASE + patch
results in;
FreeBSD/sparc64 bootstrap loader, Revision 1.0
(r...@snap.freebsd.org, Fri Jan 17 11:27:27 UTC 2014)
bootpath=/pci@1f,0/pci@1/scsi@8/disk@0,0:a
Loading /boot/defaults/loader.conf
/boot/kernel/kernel text=0xafe440 data=0xcbf60+0xd82b0
syms=[0x8+0xc53a0+0x8+0xb7c06]
/boot/kernel/zfs.ko text=0x223328 data=0xa4c0+0x17f60
syms=[0x8+0x19788+0x8+0x143eb]
loading required module 'opensolaris'
/boot/kernel/opensolaris.ko text=0x30d0 data=0x2a8+0x2030
syms=[0x8+0xd68+0x8+0x91c]
/boot/kernel/geom_mirror.ko text=0x383f0 data=0x590+0x20
syms=[0x8+0x1680+0x8+0x1191]
Hit [Enter] to boot immediately, or any other key for command prompt.
Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc00a.
Copyright (c) 1992-2014 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 10.0-RELEASE #2: Sat Mar 1 21:40:27 GMT 2014
r...@v120.lerwick.hopto.org:/usr/obj/usr/src/sys/GENERIC sparc64
gcc version 4.2.1 20070831 patched [FreeBSD]
real memory = 1073741824 (1024 MB)
avail memory = 1024622592 (977 MB)
cpu0: Sun Microsystems UltraSparc-IIe Processor (648.00 MHz CPU)
random device not loaded; using insecure entropy
panic: trap: illegal instruction (kernel)
cpuid = 0
KDB: stack backtrace:
#0 0xc0884458 at trap+0x558
Uptime: 1s
Automatic reboot in 15 seconds - press a key on the console to abort
Rebooting...
Resetti
LOM event: +12h49m59s host reset
Kind Regards
Craig Butler
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEADS UP: sparc64 backend for llvm/clang imported
On 01/03/14 20:51, John-Mark Gurney wrote:
Florian Smeets wrote this message on Sat, Mar 01, 2014 at 16:28 +0100:
On 01/03/14 02:16, John-Mark Gurney wrote:
Ok, I have a new pcpu patch to try. I have only compile tested it.
It is available here:
https://www.funkthat.com/~jmg/sparc64.pcpu.patch
I've also attached it.
Craig, do you mind testing it?
My machine doesn't boot with this patch.
OK boot -v
Booting...
jumping to kernel entry at 0xc0088000.
OF_panic: sparc64_init: cannot find boot CPU node
Program terminated
{1} ok
I'm now going to try the version that dim sent.
Does it boot w/o the patch? Is this a clang built loader/kernel or
a gcc built loader/kernel that you tried the patch on?
From a quick look at the code, it doesn't look like my patch would
have effected this part of the kernel...
Ok, all of the following was with dim's version of the patch. I can
retry with your version too, but I don't think it will make a difference.
The kernel works fine with gcc, but doesn't work compiled with clang.
Booting [/boot/kernel/kernel]...
jumping to kernel entry at 0xc0088000.
OF_panic: sparc64_init: cannot find boot CPU node
Program terminated
{1} ok
So, the same panic with your and dim's patch, compiled with clang.
Userland was compiled with gcc, cc is gcc and I used CC=clang make
kernel to build the kernel with clang.
Florian
signature.asc
Description: OpenPGP digital signature
Re: HEADS UP: sparc64 backend for llvm/clang imported
On 01/03/14 02:16, John-Mark Gurney wrote:
Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100:
For building the sparc64 kernel, there is one open issue left, which is
that sys/sparc64/include/pcpu.h uses global register variables, and this
is not supported by clang. A preliminary patch for this is attached,
but it may or may not blow up your system, please beware!
The patch changes the pcpu and curpcb global register variables into
inline functions, similar to what is done on other architectures.
However, the current approach is not optimal, and the emitted code is
slightly different from what gcc outputs. Any improvements to this
patch are greatly appreciated!
Last but not least, thanks go out to Roman Divacky for his work with
llvm/clang upstream in getting the sparc64 backend into shape.
Ok, I have a new pcpu patch to try. I have only compile tested it.
It is available here:
https://www.funkthat.com/~jmg/sparc64.pcpu.patch
I've also attached it.
Craig, do you mind testing it?
My machine doesn't boot with this patch.
OK boot -v
Booting...
jumping to kernel entry at 0xc0088000.
OF_panic: sparc64_init: cannot find boot CPU node
Program terminated
{1} ok
I'm now going to try the version that dim sent.
Florian
signature.asc
Description: OpenPGP digital signature
Re: HEADS UP: sparc64 backend for llvm/clang imported
Hi,
On Fri, Feb 28, 2014 at 08:22:06PM +0100, Dimitry Andric wrote:
If you have any sparc64 hardware, and are not afraid to encounter rough
edges, please try out building and running your system with clang. To
On all my sparc64 machines the loader seems to be broken:
{0} ok boot net:dhcp
Boot device: /pci@1f,70/network@2:dhcp File and args:
1000 Mbps FDX Link up
Consoles: Open Firmware console
panic: tlb_init_sun4u: no node for bootcpu?!?!
-- Press a key on the console to reboot --
I'm booting via TFTP, the boot environment was built on amd64 with
TARGET=sparc64.
Regards
--
Michael Moll
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
HEADS UP: sparc64 backend for llvm/clang imported
Hi, In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. If you have any sparc64 hardware, and are not afraid to encounter rough edges, please try out building and running your system with clang. To do so, update to at least r262613, and enable the following options in e.g. src.conf, or in your build environment: WITH_CLANG=y WITH_CLANG_IS_CC=y WITH_LIBCPLUSPLUS=y (optional) Alternatively, if you would rather keep gcc as /usr/bin/cc for the moment, build world using just WITH_CLANG, enabling clang to be built (by gcc) and installed. After installworld, you can then set CC=clang, CXX=clang++ and CPP=clang-cpp for building another world. For building the sparc64 kernel, there is one open issue left, which is that sys/sparc64/include/pcpu.h uses global register variables, and this is not supported by clang. A preliminary patch for this is attached, but it may or may not blow up your system, please beware! The patch changes the pcpu and curpcb global register variables into inline functions, similar to what is done on other architectures. However, the current approach is not optimal, and the emitted code is slightly different from what gcc outputs. Any improvements to this patch are greatly appreciated! Last but not least, thanks go out to Roman Divacky for his work with llvm/clang upstream in getting the sparc64 backend into shape. -Dimitry clang-sparc64-pcpu-1.diff Description: Binary data signature.asc Description: Message signed with OpenPGP using GPGMail
Re: HEADS UP: sparc64 backend for llvm/clang imported
On Fri, Feb 28, 2014 at 08:22:06PM +0100, Dimitry Andric wrote: Hi, In r262613 I have merged the clang-sparc64 branch back to head. This imports an updated sparc64 backend for llvm and clang, allowing clang to bootstrap itself on sparc64, and to completely build world. To be able to build the GENERIC kernel, there is still one patch to be finalized, see below. Wow! Great work all! I really didn't expect that we'd end up with a viable sparc64 backend in clang given how long it sat on the sidelines and the fact that the clang ports have been marked broken there for years. -- Brooks pgpb2fAGDcUTG.pgp Description: PGP signature
Re: HEADS UP: sparc64 backend for llvm/clang imported
Dimitry Andric wrote this message on Fri, Feb 28, 2014 at 20:22 +0100:
In r262613 I have merged the clang-sparc64 branch back to head. This
imports an updated sparc64 backend for llvm and clang, allowing clang to
bootstrap itself on sparc64, and to completely build world. To be able
to build the GENERIC kernel, there is still one patch to be finalized,
see below.
If you have any sparc64 hardware, and are not afraid to encounter rough
edges, please try out building and running your system with clang. To
do so, update to at least r262613, and enable the following options in
e.g. src.conf, or in your build environment:
WITH_CLANG=y
WITH_CLANG_IS_CC=y
WITH_LIBCPLUSPLUS=y (optional)
Alternatively, if you would rather keep gcc as /usr/bin/cc for the
moment, build world using just WITH_CLANG, enabling clang to be built
(by gcc) and installed. After installworld, you can then set CC=clang,
CXX=clang++ and CPP=clang-cpp for building another world.
For building the sparc64 kernel, there is one open issue left, which is
that sys/sparc64/include/pcpu.h uses global register variables, and this
is not supported by clang. A preliminary patch for this is attached,
but it may or may not blow up your system, please beware!
The patch changes the pcpu and curpcb global register variables into
inline functions, similar to what is done on other architectures.
However, the current approach is not optimal, and the emitted code is
slightly different from what gcc outputs. Any improvements to this
patch are greatly appreciated!
Last but not least, thanks go out to Roman Divacky for his work with
llvm/clang upstream in getting the sparc64 backend into shape.
Ok, I have a new pcpu patch to try. I have only compile tested it.
It is available here:
https://www.funkthat.com/~jmg/sparc64.pcpu.patch
I've also attached it.
Craig, do you mind testing it?
This patch also removes curpcb as it appears to not be used by any
sparc64 C code. A GENERIC kernel compiles fine, and fxr only turns up
curpcb used in machdep code, and no references to it under sparc64.
This is not a proper solution in that
it can mean counters/stats can be copied/moved to other cpus overwriting
the previous values if a race happens... We use
PCPU_SET(mem, PCPU_GET(mem) + val) for PCPU_ADD, not great, but it's
no worse than what we were previously using..
Until we get a proper fix which involves mapping all the cpu's PCPU
data on all CPUs, this will have to sufice..
This patch is based upon, I believe, a patch from Marius and possibly
modified by rdivacky.
Thanks for testing..
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
Index: pcpu.h
===
--- pcpu.h (revision 261863)
+++ pcpu.h (working copy)
@@ -70,11 +70,82 @@
struct pcb;
struct pcpu;
-register struct pcb *curpcb __asm__(__XSTRING(PCB_REG));
-register struct pcpu *pcpup __asm__(__XSTRING(PCPU_REG));
+/*
+ * Evaluates to the byte offset of the per-cpu variable name.
+ */
+#define __pcpu_offset(name) \
+ __offsetof(struct pcpu, name)
-#define PCPU_GET(member) (pcpup-pc_ ## member)
+/*
+ * Evaluates to the type of the per-cpu variable name.
+ */
+#define __pcpu_type(name) \
+ __typeof(((struct pcpu *)0)-name)
+#define __PCPU_GET(name) __extension__ ({ \
+ __pcpu_type(name) __res; \
+ \
+ switch (sizeof(__res)) { \
+ case 1:\
+ __asm __volatile(ldub [% __XSTRING(PCPU_REG) + %1], %0 \
+ : =r (__res) : i (__pcpu_offset(name))); \
+ break; \
+ case 2:\
+ __asm __volatile(lduh [% __XSTRING(PCPU_REG) + %1], %0\
+ : =r (__res) : i (__pcpu_offset(name))); \
+ break; \
+ case 4:\
+ __asm __volatile(ld [% __XSTRING(PCPU_REG) + %1], %0\
+ : =r (__res) : i (__pcpu_offset(name))); \
+ break; \
+ case 8:\
+ __asm __volatile(ldd [% __XSTRING(PCPU_REG) + %1], %0\
+ : =r (__res) : i (__pcpu_offset(name))); \
+ break; \
+ default: \
+ /* XXX - what to put here? */;\
+ }\
+ __res;\
+ })
+
+#define __PCPU_SET(name, val) __extension__ ({ \
+ __pcpu_type(name) __val; \
+ \
+ __val = (val); \
+ switch (sizeof(__val)) { \
+ case 1:\
+ __asm __volatile(stub %0, [% __XSTRING(PCPU_REG) + %1] \
+ : : r (__val), i (__pcpu_offset(name))); \
+ break; \
+ case 2:\
+ __asm __volatile(stuh %0, [% __XSTRING(PCPU_REG) + %1]\
+ : : r (__val), i (__pcpu_offset(name))); \
+ break; \
+ case 4:\
+ __asm __volatile(st %0, [% __XSTRING(PCPU_REG) + %1]\
+ : : r (__val), i (__pcpu_offset(name))); \
+ break; \
+ case 8:\
+ __asm __volatile(std %0, [% __XSTRING(PCPU_REG) + %1]\
+ : : r (__val), i (__pcpu_offset(name))); \
+ break; \
+ default: \
+ /* XXX - what to put here? */;\
+ }\
+ __val;\
+ })
