[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 Ian Lance Taylor changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #22 from Ian Lance Taylor --- Yes, closing this issue.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 Eric Gallager changed: What|Removed |Added CC||egallager at gcc dot gnu.org --- Comment #21 from Eric Gallager --- (In reply to Ian Lance Taylor from comment #20) > This will be in GCC 8. > > Backports to GCC 7 are fine with me but I'm not going to do them myself. GCC 7 branch is closed now, isn't it?
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #20 from Ian Lance Taylor --- This will be in GCC 8. Backports to GCC 7 are fine with me but I'm not going to do them myself.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #19 from John Paul Adrian Glaubitz --- (In reply to Ian Lance Taylor from comment #18) > OK, the SH support patch is committed, and the exp directory has been > removed. > > Is there anything else to do here? I don't think so. But it would be nice if this could get backported to gcc-7 or at least gcc-8. Thanks, Adrian
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #18 from Ian Lance Taylor --- OK, the SH support patch is committed, and the exp directory has been removed. Is there anything else to do here?
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #17 from Ian Lance Taylor --- Actually we should just drop the libgo/go/exp directory. I don't know why it's still there. It should have been dropped years ago.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #16 from John Paul Adrian Glaubitz --- As for ioctl(): Linux: http://man7.org/linux/man-pages/man2/ioctl.2.html FreeBSD: https://www.freebsd.org/cgi/man.cgi?query=ioctl=2 Plan9: https://github.com/brho/plan9/blob/master/sys/src/ape/lib/bsd/ioctl.c#L26 Darwin: https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man2/ioctl.2.html So, I really think ioctl() should be declared in libgo/go/exp/terminal/util.go accordingly: //extern ioctl func ioctl(int, uint, unsafe.Pointer) int Shall I send a separate patch?
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #15 from John Paul Adrian Glaubitz --- Thanks Oleg! (In reply to Oleg Endo from comment #14) > (In reply to John Paul Adrian Glaubitz from comment #13) > Cache line sizes of original SH implementations: > > SH2,SH2A,SH3: 16 bytes > SH4, SH4A: 32 bytes I guess I can add a case matching for sh(2|3)*-*-* and one for sh4*-*-* then. > > PC quantum should be 2 bytes as SH uses a 16-bit instruction encoding. > > > > SH2A and SH-DSP have actually 4 byte instructions. There are also some late > SH4A variants which can do 16-bit prefixes, resulting in 4 byte instructions. > > Other (newer) SH implementations might deviate from the originals and use > multiple-length instructions or different cache line sizes. I think J-Core planned to stay with the 16-bit encoding. I tested it with PC_QUANTUM=2 and it works on my SH-4A machine. > But I don't think that matters a lot. E.g. 68K has variable length > instructions and GOARCH_PCQUANTUM=4. Not sure how much the cache line size > is of an importance for libgo ... Ok. > > No idea about GOARCH_MINFRAMESIZE though. > > > > Patch submitted here: > > https://gcc.gnu.org/ml/gcc-patches/2017-12/msg0.html > > That looks OK. On SH the minimum stack pointer alignment is 4. Great, thank you!
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #14 from Oleg Endo --- (In reply to John Paul Adrian Glaubitz from comment #13) > Cacheline size is 32 bytes according to the documentation: > > > www.st.com/resource/en/user_manual/cd00147165.pdf (page 75) Cache line sizes of original SH implementations: SH2,SH2A,SH3: 16 bytes SH4, SH4A: 32 bytes > > PC quantum should be 2 bytes as SH uses a 16-bit instruction encoding. > SH2A and SH-DSP have actually 4 byte instructions. There are also some late SH4A variants which can do 16-bit prefixes, resulting in 4 byte instructions. Other (newer) SH implementations might deviate from the originals and use multiple-length instructions or different cache line sizes. But I don't think that matters a lot. E.g. 68K has variable length instructions and GOARCH_PCQUANTUM=4. Not sure how much the cache line size is of an importance for libgo ... > No idea about GOARCH_MINFRAMESIZE though. > > Patch submitted here: > https://gcc.gnu.org/ml/gcc-patches/2017-12/msg0.html That looks OK. On SH the minimum stack pointer alignment is 4.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #13 from John Paul Adrian Glaubitz --- Cacheline size is 32 bytes according to the documentation: > www.st.com/resource/en/user_manual/cd00147165.pdf (page 75) PC quantum should be 2 bytes as SH uses a 16-bit instruction encoding. No idea about GOARCH_MINFRAMESIZE though. Patch submitted here: https://gcc.gnu.org/ml/gcc-patches/2017-12/msg0.html
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #12 from James Clarke ---
> What is the value of TIOCGWINSZ on SH?
It's 0x80087468, which is the expansion of _IOR('t', 104, struct winsize) (sh4
uses the default encoding for _IOC; also for some reason the value is
hard-coded in the header)
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #11 from Ian Lance Taylor --- As far as I know libbacktrace and libgo use the same criteria for whether they are built or not. Why is libbacktrace not being built for m4-fpu? What is preventing that build from occurring? What is the value of TIOCGWINSZ on SH? What is the output of grep TIOCGWINSZ TARGET/libgo/sysinfo.go ?
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308
--- Comment #10 from John Paul Adrian Glaubitz ---
Oh, and it seems the function signature for ioctl is wrong:
./libtool: line 1143: warning: setlocale: LC_ALL: cannot change locale
(en_US.UTF-8)
../../../src/libgo/go/exp/terminal/util.go:70:23: error: integer constant
overflow
if ioctl(fd, syscall.TIOCGWINSZ, unsafe.Pointer()) < 0 {
^
Makefile:3342: recipe for target 'exp/terminal.lo' failed
Changing the second parameter to 'uint' fixes this issue:
//extern ioctl
func ioctl(int, uint, unsafe.Pointer) int
which also matches what "man ioctl" says:
SYNOPSIS
#include
int ioctl(int fd, unsigned long request, ...);
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #9 from John Paul Adrian Glaubitz --- I have added "sh" to all relevant places and after uncovering a bug in qemu-sh4, I managed to build libgo but the no-fpu variant eventually fails to link: make[4]: Entering directory '/build/gcc-7-COw15T/gcc-7-7.2.0/build/sh4-linux-gnu/m4-nofpu/libgo' /usr/bin/make "AR_FLAGS=" "CC_FOR_BUILD=sh4-linux-gnu-gcc-7" "CC_FOR_TARGET=" "CFLAGS=-g -O2 -m4-nofpu" "CXXFLAGS=-m4-nofpu" "CFLAGS_FOR_BUILD=" "CFLAGS_FOR_TARGET=" "GOC_FOR_TARGET=" "GOC=/build/gcc-7-COw15T/gcc-7-7.2.0/build/./gcc/gccgo -B/build/gcc-7-COw15T/gcc-7-7.2.0/build/./gcc/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem /build/gcc-7-COw15T/gcc-7-7.2.0/build/sys-include " "GOCFLAGS=-g -O2 -m4-nofpu" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-Wl,-z,relro -m4-nofpu" "LIBCFLAGS=-m4-nofpu" "LIBCFLAGS_FOR_TARGET=" "MAKE=/usr/bin/make" "MAKEINFO=makeinfo --split-size=500 " "PICFLAG=" "PICFLAG_FOR_TARGET=" "SHELL=/bin/bash" "RUNTESTFLAGS=" "exec_prefix=/usr" "infodir=/usr/share/info" "libdir=/usr/lib" "includedir=/usr/include" "prefix=/usr" "tooldir=" "gxx_include_dir=" "AR=sh4-linux-gnu-ar" "AS=as" "LD=/build/gcc-7-COw15T/gcc-7-7.2.0/build/./gcc/collect-ld" "RANLIB=sh4-linux-gnu-ranlib" "NM=/build/gcc-7-COw15T/gcc-7-7.2.0/build/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=" "DESTDIR=" "WERROR=" all-recursive make[5]: Entering directory '/build/gcc-7-COw15T/gcc-7-7.2.0/build/sh4-linux-gnu/m4-nofpu/libgo' make[6]: Entering directory '/build/gcc-7-COw15T/gcc-7-7.2.0/build/sh4-linux-gnu/m4-nofpu/libgo' make[6]: *** No rule to make target '../libbacktrace/libbacktrace.la', needed by 'libgo.la'. Stop. make[6]: Leaving directory '/build/gcc-7-COw15T/gcc-7-7.2.0/build/sh4-linux-gnu/m4-nofpu/libgo' Makefile:2757: recipe for target 'all-recursive' failed make[5]: *** [all-recursive] Error 1 Looking at the build directory, libbacktrace is built: (sid-sh4-sbuild)root@nofan:/build/gcc-7-COw15T/gcc-7-7.2.0/build/sh4-linux-gnu/libgo# ls .. libada libatomic libbacktrace libffi libgcc libgnatvsn libgo libgomp libstdc++-v3 m4-nofpu (sid-sh4-sbuild)root@nofan:/build/gcc-7-COw15T/gcc-7-7.2.0/build/sh4-linux-gnu/libgo# But not for the m4-nofpu variant: (sid-sh4-sbuild)root@nofan:/build/gcc-7-COw15T/gcc-7-7.2.0/build/sh4-linux-gnu/m4-nofpu/libgo# ls .. libffi libgo libgomp libstdc++-v3 (sid-sh4-sbuild)root@nofan:/build/gcc-7-COw15T/gcc-7-7.2.0/build/sh4-linux-gnu/m4-nofpu/libgo# Hence "../libbacktrace/libbacktrace.la" is not found when m4-fpu/libgo/libgo.la is being linked. Is there a way to disable libgo for m4-fpu?
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #8 from John Paul Adrian Glaubitz --- (In reply to Ian Lance Taylor from comment #7) > Sorry, I did not mean to imply that I listed all the changes required. I'm > sure there will be many more, though likely mostly simple. Ah, I misunderstood then. I'll just go through the code then and check where else we need to SH. > For the ones you mention, you'll need to add "sh" to the +build lines in > libgo/go/runtime/hash32.go and libgo/go/runtime/lfstack_32bit.go. Will do. Thanks!
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #7 from Ian Lance Taylor --- Sorry, I did not mean to imply that I listed all the changes required. I'm sure there will be many more, though likely mostly simple. For the ones you mention, you'll need to add "sh" to the +build lines in libgo/go/runtime/hash32.go and libgo/go/runtime/lfstack_32bit.go.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #6 from John Paul Adrian Glaubitz --- Seems like the changes suggested by Ian aren't enough: libtool: compile: /<>/build/./gcc/gccgo -B/<>/build/./gcc/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem /<>/build/sys-include -O2 -g -I . -c -fgo-pkgpath=runtime >>-fgo-c-header=runtime.inc.tmp -fgo-compiling-runtime >>../../../src/libgo/go/runtime/alg.go >>../../../src/libgo/go/runtime/cgo_gccgo.go >>../../../src/libgo/go/runtime/chan.go ../../../ src/libgo/go/runtime/compiler.go ../../../src/libgo/go/runtime/cpuprof.go ../../../src/libgo/go/runtime/cputicks.go ../../../src/libgo/go/runtime/debug.go ../../../src/libgo/go/runtime/env_posix.go ../../../src/libgo/go/runtime/error.go ../../../src/libgo/go/runtime/extern.go ../../../src/libgo/go/runtime/ffi.go ../../../src/libgo/go/runtime/hashmap.go ../../../src/libgo/go/runtime/hashmap_fast.go ../../../src/libgo/go/runtime/iface.go ../../../src/libgo/go/runtime/lfst ack.go ../../../src/libgo/go/runtime/lock_futex.go ../../../src/libgo/go/runtime/mcache.go ../../../src/libgo/go/runtime/mprof.go ../../../src/libgo/go/runtime/msan0.go ../../../src/libgo/go/runtime/mstats.go ../../../src/libgo/go/runtim e/netpoll.go ../../../src/libgo/go/runtime/netpoll_epoll.go ../../../src/libgo/go/runtime/os_gccgo.go ../../../src/libgo/go/runtime/os_linux.go ../../../src/libgo/go/runtime/panic.go ../../../src/libgo/go/runtime/print.go ../../../src/li bgo/go/runtime/proc.go ../../../src/libgo/go/runtime/race0.go ../../../src/libgo/go/runtime/rdebug.go ../../../src/libgo/go/runtime/runtime.go ../../../src/libgo/go/runtime/runtime1.go ../../../src/libgo/go/runtime/runtime2.go ../../../s rc/libgo/go/runtime/select.go ../../../src/libgo/go/runtime/sema.go ../../../src/libgo/go/runtime/signal_gccgo.go ../../../src/libgo/go/runtime/signal_sighandler.go ../../../src/libgo/go/runtime/signal_unix.go ../../../src/libgo/go/runti me/sigqueue.go ../../../src/libgo/go/runtime/sizeclasses.go ../../../src/libgo/go/runtime/slice.go ../../../src/libgo/go/runtime/string.go ../../../src/libgo/go/runtime/stubs.go ../../../src/libgo/go/runtime/stubs2.go ../../../src/libgo/ go/runtime/symtab.go ../../../src/libgo/go/runtime/time.go ../../../src/libgo/go/runtime/trace.go ../../../src/libgo/go/runtime/traceback_gccgo.go ../../../src/libgo/go/runtime/type.go ../../../src/libgo/go/runtime/typekind.go ../../../s rc/libgo/go/runtime/utf8.go ../../../src/libgo/go/runtime/write_err.go runtime_sysinfo.go sigtab.go -fPIC -o .libs/runtime.o ../../../src/libgo/go/runtime/alg.go:61:9: error: reference to undefined name 'memhash' return memhash(p, h, 1) ^ ../../../src/libgo/go/runtime/alg.go:64:9: error: reference to undefined name 'memhash' return memhash(p, h, 2) ^ ../../../src/libgo/go/runtime/alg.go:67:9: error: reference to undefined name 'memhash' return memhash(p, h, 4) ^ ../../../src/libgo/go/runtime/alg.go:70:9: error: reference to undefined name 'memhash' return memhash(p, h, 8) ^ ../../../src/libgo/go/runtime/alg.go:73:9: error: reference to undefined name 'memhash' return memhash(p, h, 16) ^ ../../../src/libgo/go/runtime/alg.go:92:9: error: reference to undefined name 'memhash' return memhash(x.str, h, uintptr(x.len)) ^ ../../../src/libgo/go/runtime/alg.go:108:10: error: reference to undefined name 'memhash' return memhash(p, h, 4) ^ ../../../src/libgo/go/runtime/alg.go:120:10: error: reference to undefined name 'memhash' return memhash(p, h, 8) ^ ../../../src/libgo/go/runtime/alg.go:325:9: error: reference to undefined name 'memhash' return memhash(p, h, unsafe.Sizeof(unsafe.Pointer)) ^ ../../../src/libgo/go/runtime/alg.go:334:9: error: reference to undefined name 'memhash' var _ = memhash ^ libtool: compile: /<>/build/./gcc/xgcc -B/<>/build/./gcc/ -B/usr/sh4-linux-gnu/bin/ -B/usr/sh4-linux-gnu/lib/ -isystem /usr/sh4-linux-gnu/include -isystem /usr/sh4-linux-gnu/sys-include -isystem /<>/build/sys-include -DHAVE_CONFIG_H -I. -I../../../src/libgfortran -iquote../../../src/libgfortran/io -I../../../src/libgfortran/../gcc -I../../../src/libgfortran/../gcc/config -I../.././gcc -I../../../src/libgfortran/../libgcc -I../libgcc -I../../../src/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections -mieee -g -O2 -MT maxloc1_4_r4.lo -MD -MP -MF .deps/maxloc1_4_r4.Tpo -c ../../../src/libgfortran/generated/maxloc1_4_r4.c -o maxloc1_4_r4.o >/dev/null 2>&1 ../../../src/libgo/go/runtime/lfstack.go:24:9: error: reference to undefined name 'lfstackPack' new := lfstackPack(node, node.pushcnt) ^
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #5 from John Paul Adrian Glaubitz --- (In reply to Ian Lance Taylor from comment #4) > gccgo does work on a number of targets that do not have split stack support. > The downsides are that each goroutine has a much larger stack, and if you > have too much recursion you can run out of stack space and crash. But most > programs work fine. I'll give it a try and if it works, I'll send a patch :).
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #4 from Ian Lance Taylor --- gccgo does work on a number of targets that do not have split stack support. The downsides are that each goroutine has a much larger stack, and if you have too much recursion you can run out of stack space and crash. But most programs work fine.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #3 from Oleg Endo --- Go will not work on SH just by adding it to the list of targets. For instance split stacks support is not implemented on SH.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #2 from Ian Lance Taylor --- I suspect you'll need other changes as well, such as a new file libgo/go/internal/syscall/unix/getrandom_linux_sh.go. For that matter you'll need to add sh to libgo/go/go/build/syslist.go and to match.sh and libgo/match.sh and libgo/testsuite/gotest.
[Bug go/83308] Missing platform definitions for SH in libgo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83308 --- Comment #1 from Rich Felker --- If PCQUANTUM is the minimum unit/alignment for the program counter, which it sounds like, then the value should be 2 not 4. SH has 16-bit opcodes.
