diff mbox series

Correct goarch.sh settings for gccgo on hppa?

Message ID 7013a3e7d6c9c77c5010bc1c72971758@matoro.tk (mailing list archive)
State Handled Elsewhere, archived
Headers show
Series Correct goarch.sh settings for gccgo on hppa? | expand

Commit Message

matoro Nov. 25, 2022, 6 p.m. UTC
Hi, I was recommended to ask here but I'm trying to enable gccgo to run 
on parisc, however I am not sure what the proper values should be for 
the arch configuration settings.  The description is as follows:

# Code in Makefile.am will invoke this script with two arguments.
# The first is a GOARCH value.  The second is a keyword.
# The script will print the value of that keyword for that GOARCH.
# Keywords:
# - bigendian: true or false
# - cachelinesize: the cache line size in bytes
#	(for performance only; it's not essential to get this right)
# - defaultphyspagesize: the default physical page size in bytes
#	(not currently used, but maybe some day)
# - family: the processor family, from ALLGOARCHFAMILY in configure.ac
# - int64align: alignment of int64 type in bytes
# - maxalign: maximum alignment of values of Go types in bytes
# - minframesize: size of smallest possible function frame in bytes
#	(not currently used, may never be used)
# - pcquantum: minimum size of a single instruction in bytes
# - ptrsize: size of a pointer in bytes

There is also an undocumented "stackalign" variable.

# Default values
bigendian=false
cachelinesize=64
defaultphyspagesize=4096
family=unknown
int64align=8
maxalign=8
minframesize=0
pcquantum=1
ptrsize=8
stackalign=8

This was what I first attempted to set, according to a brief skim of the 
ISA manual:


However this was clearly wrong, because while it did build, the 
resulting binary immediately segfaults.

unexpected fault address 0x33d8effc
fatal error: fault
[signal SIGSEGV: segmentation violation code=0x1 addr=0x33d8effc 
pc=0xf58f4284]

goroutine 4 [running]:
runtime.dopanic__m
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1207
runtime.fatalthrow
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1073
runtime.throw
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1044
runtime.sigpanic
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/signal_unix.go:714
net_1http.connectMethod.scheme
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1829
net_1http.Transport.dialConn
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1612
net_1http.Transport.dialConnFor
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1449
runtime.kickoff
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/proc.go:1316
created by net_1http.Transport.queueForDial
	/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1418 
+0x37b


Is there anybody who might be able to advise on what these values should 
be for parisc?

Comments

Helge Deller Nov. 25, 2022, 6:31 p.m. UTC | #1
Hi Matoro,

On 11/25/22 19:00, matoro wrote:
> Hi, I was recommended to ask here but I'm trying to enable gccgo to
> run on parisc,

That would be fantastic!!!

> however I am not sure what the proper values should be
> for the arch configuration settings.  The description is as follows:
>
> # Code in Makefile.am will invoke this script with two arguments.
> # The first is a GOARCH value.  The second is a keyword.
> # The script will print the value of that keyword for that GOARCH.
> # Keywords:
> # - bigendian: true or false

true

> # - cachelinesize: the cache line size in bytes
> #    (for performance only; it's not essential to get this right)

32

> # - defaultphyspagesize: the default physical page size in bytes
> #    (not currently used, but maybe some day)

4096 bytes

> # - family: the processor family, from ALLGOARCHFAMILY in configure.ac

I think "hppa", but could be "parisc" too...
uname reports back parisc (on 32bit kernel) or parisc64 (on 64-bit kernel).

> # - int64align: alignment of int64 type in bytes

8 bytes

> # - maxalign: maximum alignment of values of Go types in bytes

?

> # - minframesize: size of smallest possible function frame in bytes
> #    (not currently used, may never be used)

I think 64 bytes.

> # - pcquantum: minimum size of a single instruction in bytes

Every assembler statement is always 4 bytes.

> # - ptrsize: size of a pointer in bytes

4 bytes   (would be 8 bytes for 64-bit userspace which we don't have yet).

> There is also an undocumented "stackalign" variable.

64 bytes.

> # Default values
> bigendian=false
> cachelinesize=64
> defaultphyspagesize=4096
> family=unknown
> int64align=8
> maxalign=8
> minframesize=0
> pcquantum=1
> ptrsize=8
> stackalign=8
>
> This was what I first attempted to set, according to a brief skim of the ISA manual:
>
> diff --git a/libgo/goarch.sh b/libgo/goarch.sh
> index 977f318b3..ed40815ac 100755
> --- a/libgo/goarch.sh
> +++ b/libgo/goarch.sh
> @@ -88,6 +88,16 @@ case $goarch in
>           ;;
>       esac
>       ;;
> +    hppa)
> +    family=HPPA
> +    bigendian=true
> +    defaultphyspagesize=4096
> +    minframesize=16

this should be 64bytes.

> +    int64align=8
> +    stackalign=4
> +    pcquantum=4
> +    ptrsize=4
> +    ;;
>       ia64)
>       family=IA64
>       cachelinesize=128
>
> However this was clearly wrong, because while it did build, the resulting binary immediately segfaults.
>
> unexpected fault address 0x33d8effc
> fatal error: fault
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x33d8effc pc=0xf58f4284]
>
> goroutine 4 [running]:
> runtime.dopanic__m
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1207
> runtime.fatalthrow
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1073
> runtime.throw
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1044
> runtime.sigpanic
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/signal_unix.go:714
> net_1http.connectMethod.scheme
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1829
> net_1http.Transport.dialConn
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1612
> net_1http.Transport.dialConnFor
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1449
> runtime.kickoff
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/proc.go:1316
> created by net_1http.Transport.queueForDial
>      /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1418 +0x37b
>
>
> Is there anybody who might be able to advise on what these values should be for parisc?

Helge
John David Anglin Nov. 25, 2022, 6:45 p.m. UTC | #2
I added some comments below.

Some years ago we hacked on gcc to add the go language but we didn't get it working.

Dave

On 2022-11-25 1:00 p.m., matoro wrote:
> Hi, I was recommended to ask here but I'm trying to enable gccgo to run on parisc, however I am not sure what the proper values should be for 
> the arch configuration settings.  The description is as follows:
>
> # Code in Makefile.am will invoke this script with two arguments.
> # The first is a GOARCH value.  The second is a keyword.
> # The script will print the value of that keyword for that GOARCH.
> # Keywords:
> # - bigendian: true or false
> # - cachelinesize: the cache line size in bytes
> #    (for performance only; it's not essential to get this right)
> # - defaultphyspagesize: the default physical page size in bytes
> #    (not currently used, but maybe some day)
> # - family: the processor family, from ALLGOARCHFAMILY in configure.ac
> # - int64align: alignment of int64 type in bytes
> # - maxalign: maximum alignment of values of Go types in bytes
> # - minframesize: size of smallest possible function frame in bytes
> #    (not currently used, may never be used)
> # - pcquantum: minimum size of a single instruction in bytes
> # - ptrsize: size of a pointer in bytes
>
> There is also an undocumented "stackalign" variable.
>
> # Default values
> bigendian=false
> cachelinesize=64
Depends on processor.  Max is 128 on machines with PA8800/PA8900 processors.
> defaultphyspagesize=4096
> family=unknown
> int64align=8
> maxalign=8
> minframesize=0
> pcquantum=1
> ptrsize=8
> stackalign=8
>
> This was what I first attempted to set, according to a brief skim of the ISA manual:
>
> diff --git a/libgo/goarch.sh b/libgo/goarch.sh
> index 977f318b3..ed40815ac 100755
> --- a/libgo/goarch.sh
> +++ b/libgo/goarch.sh
> @@ -88,6 +88,16 @@ case $goarch in
>          ;;
>      esac
>      ;;
> +    hppa)
> +    family=HPPA
> +    bigendian=true
> +    defaultphyspagesize=4096
> +    minframesize=16
I think this should be 0 when frame isn't needed.  In 32-bit runtime, minimum frame size is 64
when a frame is allocated.
> + int64align=8
> +    stackalign=4
This probably should be 16.  It needs to be at least 8 for double and int64_t.  It was set to 16
for ldcw semaphores. This was needed for the original pthread implementation. Malloc alignment
is 16.  However, this causes some issues with over alignment in some package builds.
> + pcquantum=4
> +    ptrsize=4
> +    ;;
>      ia64)
>      family=IA64
>      cachelinesize=128
>
> However this was clearly wrong, because while it did build, the resulting binary immediately segfaults.
>
> unexpected fault address 0x33d8effc
> fatal error: fault
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x33d8effc pc=0xf58f4284]
One would need to debug to find the cause...
>
> goroutine 4 [running]:
> runtime.dopanic__m
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1207
> runtime.fatalthrow
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1073
> runtime.throw
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1044
> runtime.sigpanic
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/signal_unix.go:714
> net_1http.connectMethod.scheme
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1829
> net_1http.Transport.dialConn
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1612
> net_1http.Transport.dialConnFor
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1449
> runtime.kickoff
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/proc.go:1316
> created by net_1http.Transport.queueForDial
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1418 +0x37b
>
>
> Is there anybody who might be able to advise on what these values should be for parisc?
matoro Nov. 26, 2022, 4:31 a.m. UTC | #3
Thank you both for the suggestions.  I tried the following values:

diff --git a/libgo/goarch.sh b/libgo/goarch.sh
index 977f318b3..e0d6a3ad8 100755
--- a/libgo/goarch.sh
+++ b/libgo/goarch.sh
@@ -88,6 +88,16 @@ case $goarch in
                 ;;
         esac
         ;;
+    hppa)
+       bigendian=true
+       defaultphyspagesize=4096
+       family=HPPA
+       int64align=8
+       minframesize=64
+       pcquantum=4
+       ptrsize=4
+       stackalign=64
+       ;;
      ia64)
         family=IA64
         cachelinesize=128

But unfortunately got the same result.  I wonder if there is something 
else missing?

Ian, if you have the time, I have a machine you can use to look at this.

-------- Original Message --------
Subject: Re: Correct goarch.sh settings for gccgo on hppa?
Date: 2022-11-25 13:45
 From: John David Anglin <dave.anglin@bell.net>
To: matoro <matoro_mailinglist_kernel@matoro.tk>, 
linux-parisc@vger.kernel.org

I added some comments below.

Some years ago we hacked on gcc to add the go language but we didn't get 
it working.

Dave

On 2022-11-25 1:00 p.m., matoro wrote:
> Hi, I was recommended to ask here but I'm trying to enable gccgo to run 
> on parisc, however I am not sure what the proper values should be for 
> the arch configuration settings.  The description is as follows:
> 
> # Code in Makefile.am will invoke this script with two arguments.
> # The first is a GOARCH value.  The second is a keyword.
> # The script will print the value of that keyword for that GOARCH.
> # Keywords:
> # - bigendian: true or false
> # - cachelinesize: the cache line size in bytes
> #    (for performance only; it's not essential to get this right)
> # - defaultphyspagesize: the default physical page size in bytes
> #    (not currently used, but maybe some day)
> # - family: the processor family, from ALLGOARCHFAMILY in configure.ac
> # - int64align: alignment of int64 type in bytes
> # - maxalign: maximum alignment of values of Go types in bytes
> # - minframesize: size of smallest possible function frame in bytes
> #    (not currently used, may never be used)
> # - pcquantum: minimum size of a single instruction in bytes
> # - ptrsize: size of a pointer in bytes
> 
> There is also an undocumented "stackalign" variable.
> 
> # Default values
> bigendian=false
> cachelinesize=64
Depends on processor.  Max is 128 on machines with PA8800/PA8900 
processors.
> defaultphyspagesize=4096
> family=unknown
> int64align=8
> maxalign=8
> minframesize=0
> pcquantum=1
> ptrsize=8
> stackalign=8
> 
> This was what I first attempted to set, according to a brief skim of 
> the ISA manual:
> 
> diff --git a/libgo/goarch.sh b/libgo/goarch.sh
> index 977f318b3..ed40815ac 100755
> --- a/libgo/goarch.sh
> +++ b/libgo/goarch.sh
> @@ -88,6 +88,16 @@ case $goarch in
>          ;;
>      esac
>      ;;
> +    hppa)
> +    family=HPPA
> +    bigendian=true
> +    defaultphyspagesize=4096
> +    minframesize=16
I think this should be 0 when frame isn't needed.  In 32-bit runtime, 
minimum frame size is 64
when a frame is allocated.
> + int64align=8
> +    stackalign=4
This probably should be 16.  It needs to be at least 8 for double and 
int64_t.  It was set to 16
for ldcw semaphores. This was needed for the original pthread 
implementation. Malloc alignment
is 16.  However, this causes some issues with over alignment in some 
package builds.
> + pcquantum=4
> +    ptrsize=4
> +    ;;
>      ia64)
>      family=IA64
>      cachelinesize=128
> 
> However this was clearly wrong, because while it did build, the 
> resulting binary immediately segfaults.
> 
> unexpected fault address 0x33d8effc
> fatal error: fault
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x33d8effc 
> pc=0xf58f4284]
One would need to debug to find the cause...
> 
> goroutine 4 [running]:
> runtime.dopanic__m
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1207
> runtime.fatalthrow
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1073
> runtime.throw
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/panic.go:1044
> runtime.sigpanic
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/signal_unix.go:714
> net_1http.connectMethod.scheme
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1829
> net_1http.Transport.dialConn
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1612
> net_1http.Transport.dialConnFor
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1449
> runtime.kickoff
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/proc.go:1316
> created by net_1http.Transport.queueForDial
>     /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1418 
> +0x37b
> 
> 
> Is there anybody who might be able to advise on what these values 
> should be for parisc?
Ian Lance Taylor Nov. 26, 2022, 5:25 a.m. UTC | #4
On Fri, Nov 25, 2022 at 8:31 PM matoro
<matoro_mailinglist_kernel@matoro.tk> wrote:
>
> Thank you both for the suggestions.  I tried the following values:
>
> diff --git a/libgo/goarch.sh b/libgo/goarch.sh
> index 977f318b3..e0d6a3ad8 100755
> --- a/libgo/goarch.sh
> +++ b/libgo/goarch.sh
> @@ -88,6 +88,16 @@ case $goarch in
>                  ;;
>          esac
>          ;;
> +    hppa)
> +       bigendian=true
> +       defaultphyspagesize=4096
> +       family=HPPA
> +       int64align=8
> +       minframesize=64
> +       pcquantum=4
> +       ptrsize=4
> +       stackalign=64
> +       ;;
>       ia64)
>          family=IA64
>          cachelinesize=128
>
> But unfortunately got the same result.  I wonder if there is something
> else missing?
>
> Ian, if you have the time, I have a machine you can use to look at this.

As far as I know gccgo has never been ported to parisc.  This requires
a fair bit more than just fixing up goarch.sh.  There are a bunch of
files in libgo that are conditionally compiled based on the GOARCH
(processor) and GOOS (operating system) values.  These are marked in
the files by comments that start with "+build" or "go:build".  Many of
those comments will need to be adjusted to recognize parisc and
whatever operating system you are using.  If this is for HP/UX, there
is also operating specific code required in various places.

I'm happy to answer questions about doing the port, but it's not a trivial task.

Ian
matoro Nov. 26, 2022, 5:39 a.m. UTC | #5
Oh sorry, should have clarified.  I did all those parts already, just 
didn't include them because I assumed the at-fault piece would be in 
goarch.sh.  This is for Linux only.

All I did for the conditional stuff was add HPPA to all the 32-bit 
files, and add the two unique syscall numbers.  This was based on the 
instructions in configure.ac.  Here is the complete patch:  
https://dpaste.com/HVHNU9BKF.txt

Is there something I might be missing?

-------- Original Message --------
Subject: Re: Correct goarch.sh settings for gccgo on hppa?
Date: 2022-11-26 00:25
 From: Ian Lance Taylor <iant@golang.org>
To: matoro <matoro_mailinglist_kernel@matoro.tk>

On Fri, Nov 25, 2022 at 8:31 PM matoro
<matoro_mailinglist_kernel@matoro.tk> wrote:
> 
> Thank you both for the suggestions.  I tried the following values:
> 
> diff --git a/libgo/goarch.sh b/libgo/goarch.sh
> index 977f318b3..e0d6a3ad8 100755
> --- a/libgo/goarch.sh
> +++ b/libgo/goarch.sh
> @@ -88,6 +88,16 @@ case $goarch in
>                  ;;
>          esac
>          ;;
> +    hppa)
> +       bigendian=true
> +       defaultphyspagesize=4096
> +       family=HPPA
> +       int64align=8
> +       minframesize=64
> +       pcquantum=4
> +       ptrsize=4
> +       stackalign=64
> +       ;;
>       ia64)
>          family=IA64
>          cachelinesize=128
> 
> But unfortunately got the same result.  I wonder if there is something
> else missing?
> 
> Ian, if you have the time, I have a machine you can use to look at 
> this.

As far as I know gccgo has never been ported to parisc.  This requires
a fair bit more than just fixing up goarch.sh.  There are a bunch of
files in libgo that are conditionally compiled based on the GOARCH
(processor) and GOOS (operating system) values.  These are marked in
the files by comments that start with "+build" or "go:build".  Many of
those comments will need to be adjusted to recognize parisc and
whatever operating system you are using.  If this is for HP/UX, there
is also operating specific code required in various places.

I'm happy to answer questions about doing the port, but it's not a 
trivial task.

Ian
matoro Nov. 27, 2022, 6:53 a.m. UTC | #6
Surprisingly yes, a trivial program does work.  Seems the problems only 
arise on anything more than that.

$ go version
go version go1.18 gccgo (Gentoo 12.2.1_p20221008 p1) 12.2.1 20221008 
linux/hppa
$ cat test.go
package main
import "fmt"
func main() {
     fmt.Println("Hello World!")
}
$ go build test.go
$ ./test
Hello World!

Main issue is that the exact stacktrace is different in between runs.  I 
tried setting GOMAXPROCS=1 in order to make it reproducible but that 
completely changed the error.

$ GOMAXPROCS=1 go install github.com/gokcehan/lf@latest
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x0]

goroutine 15 [running]:
memchr
         :0
created by net_1http.Transport.queueForDial
         
/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1418 
+0x37b

Here is as much info as I am able to get out of gdb:

$ GOMAXPROCS=1 gdb --quiet --args /usr/local/bin/go install 
github.com/gokcehan/lf@latest
Reading symbols from /usr/local/bin/go...
Reading symbols from 
/usr/lib/debug//usr/hppa2.0-unknown-linux-gnu/gcc-bin/12/go-12.debug...
(gdb) r
Starting program: /usr/local/bin/go install 
github.com/gokcehan/lf@latest
warning: Unable to find libthread_db matching inferior's thread library, 
thread debugging will not be available.
[New LWP 7838]
[New LWP 7839]

Thread 3 "go" received signal SIGSEGV, Segmentation fault.
[Switching to LWP 7839]
0xf7556aa8 in memcmp () from /lib/libc.so.6
(gdb) bt full
#0  0xf7556aa8 in memcmp () from /lib/libc.so.6
No symbol table info available.
#1  0xf8d41134 in net_1http.Transport.dialConn (t=0x41a90340, 
t@entry=0x41acc370, ctx=..., param=...)
     at 
/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1645
         trace = 0x0
         wrapErr = 0x433107ec
         cm = 0x4180b950
         pconn = 0x41acc370
         err = {__methods = 0x0, __object = 0x0}
#2  0xf8d42b7c in net_1http.Transport.dialConnFor (t=0x41acc370, 
w=0x4180b950)
     at 
/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1449
         pc = <optimized out>
         err = <optimized out>
         delivered = <optimized out>
#3  0xf8d42eb4 in net/http.go..thunk166 (__go_thunk_parameter=<optimized 
out>)
     at 
/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1418
No locals.
#4  0xf8ea2264 in runtime.kickoff ()
     at 
/var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/proc.go:1316
         gp = 0x4180b950
         fv = 0x4180e5b8
         param = 0x41acc370
#5  0xf74f4284 in setcontext () from /lib/libc.so.6
No symbol table info available.
#6  0x00000000 in ?? ()
No symbol table info available.
Backtrace stopped: previous frame identical to this frame (corrupt 
stack?)

This seems to have something at least, is it useful?

-------- Original Message --------
Subject: Re: Correct goarch.sh settings for gccgo on hppa?
Date: 2022-11-26 22:17
 From: Ian Lance Taylor <iant@golang.org>
To: matoro <matoro_mailinglist_kernel@matoro.tk>

On Fri, Nov 25, 2022, 9:39 PM matoro 
<matoro_mailinglist_kernel@matoro.tk>
wrote:

> Oh sorry, should have clarified.  I did all those parts already, just
> didn't include them because I assumed the at-fault piece would be in
> goarch.sh.  This is for Linux only.
> 
> All I did for the conditional stuff was add HPPA to all the 32-bit
> files, and add the two unique syscall numbers.  This was based on the
> instructions in configure.ac.  Here is the complete patch:
> https://dpaste.com/HVHNU9BKF.txt
> 
> Is there something I might be missing?
> 


Good to hear you have updated the build tags.  I don't know what is 
wrong,
tough.  Can you run the failing program under the debugger and find out
where that address is coming from?

But first: does a trivial hello world program work?

Ian



-------- Original Message --------
> Subject: Re: Correct goarch.sh settings for gccgo on hppa?
> Date: 2022-11-26 00:25
>  From: Ian Lance Taylor <iant@golang.org>
> To: matoro <matoro_mailinglist_kernel@matoro.tk>
> 
> On Fri, Nov 25, 2022 at 8:31 PM matoro
> <matoro_mailinglist_kernel@matoro.tk> wrote:
> >
> > Thank you both for the suggestions.  I tried the following values:
> >
> > diff --git a/libgo/goarch.sh b/libgo/goarch.sh
> > index 977f318b3..e0d6a3ad8 100755
> > --- a/libgo/goarch.sh
> > +++ b/libgo/goarch.sh
> > @@ -88,6 +88,16 @@ case $goarch in
> >                  ;;
> >          esac
> >          ;;
> > +    hppa)
> > +       bigendian=true
> > +       defaultphyspagesize=4096
> > +       family=HPPA
> > +       int64align=8
> > +       minframesize=64
> > +       pcquantum=4
> > +       ptrsize=4
> > +       stackalign=64
> > +       ;;
> >       ia64)
> >          family=IA64
> >          cachelinesize=128
> >
> > But unfortunately got the same result.  I wonder if there is something
> > else missing?
> >
> > Ian, if you have the time, I have a machine you can use to look at
> > this.
> 
> As far as I know gccgo has never been ported to parisc.  This requires
> a fair bit more than just fixing up goarch.sh.  There are a bunch of
> files in libgo that are conditionally compiled based on the GOARCH
> (processor) and GOOS (operating system) values.  These are marked in
> the files by comments that start with "+build" or "go:build".  Many of
> those comments will need to be adjusted to recognize parisc and
> whatever operating system you are using.  If this is for HP/UX, there
> is also operating specific code required in various places.
> 
> I'm happy to answer questions about doing the port, but it's not a
> trivial task.
> 
> Ian
>
Helge Deller Nov. 27, 2022, 8:19 a.m. UTC | #7
On 11/27/22 07:53, matoro wrote:
> Surprisingly yes, a trivial program does work.  Seems the problems only arise on anything more than that.
>
> $ go version
> go version go1.18 gccgo (Gentoo 12.2.1_p20221008 p1) 12.2.1 20221008 linux/hppa
> $ cat test.go
> package main
> import "fmt"
> func main() {
>      fmt.Println("Hello World!")
> }
> $ go build test.go
> $ ./test
> Hello World!
>
> Main issue is that the exact stacktrace is different in between runs.  I tried setting GOMAXPROCS=1 in order to make it reproducible but that completely changed the error.
>
> $ GOMAXPROCS=1 go install github.com/gokcehan/lf@latest
> panic: runtime error: invalid memory address or nil pointer dereference
> [signal SIGSEGV: segmentation violation code=0x1 addr=0x40 pc=0x0]
>
> goroutine 15 [running]:
> memchr
>          :0
> created by net_1http.Transport.queueForDial
> /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1418 +0x37b
>
> Here is as much info as I am able to get out of gdb:
>
> $ GOMAXPROCS=1 gdb --quiet --args /usr/local/bin/go install github.com/gokcehan/lf@latest
> Reading symbols from /usr/local/bin/go...
> Reading symbols from /usr/lib/debug//usr/hppa2.0-unknown-linux-gnu/gcc-bin/12/go-12.debug...
> (gdb) r
> Starting program: /usr/local/bin/go install github.com/gokcehan/lf@latest
> warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
> [New LWP 7838]
> [New LWP 7839]
>
> Thread 3 "go" received signal SIGSEGV, Segmentation fault.
> [Switching to LWP 7839]
> 0xf7556aa8 in memcmp () from /lib/libc.so.6
> (gdb) bt full
> #0  0xf7556aa8 in memcmp () from /lib/libc.so.6
> No symbol table info available.
> #1  0xf8d41134 in net_1http.Transport.dialConn (t=0x41a90340, t@entry=0x41acc370, ctx=..., param=...)
>      at /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1645
>          trace = 0x0
>          wrapErr = 0x433107ec
>          cm = 0x4180b950
>          pconn = 0x41acc370
>          err = {__methods = 0x0, __object = 0x0}
> #2  0xf8d42b7c in net_1http.Transport.dialConnFor (t=0x41acc370, w=0x4180b950)
>      at /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1449
>          pc = <optimized out>
>          err = <optimized out>
>          delivered = <optimized out>
> #3  0xf8d42eb4 in net/http.go..thunk166 (__go_thunk_parameter=<optimized out>)
>      at /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/net/http/transport.go:1418
> No locals.
> #4  0xf8ea2264 in runtime.kickoff ()
>      at /var/tmp/portage/sys-devel/gcc-12.2.1_p20221008/work/gcc-12-20221008/libgo/go/runtime/proc.go:1316
>          gp = 0x4180b950
>          fv = 0x4180e5b8
>          param = 0x41acc370
> #5  0xf74f4284 in setcontext () from /lib/libc.so.6
> No symbol table info available.
> #6  0x00000000 in ?? ()
> No symbol table info available.
> Backtrace stopped: previous frame identical to this frame (corrupt stack?)
>
> This seems to have something at least, is it useful?

I don't know if it's relevant, but on hppa the stack grows upwards,
while on all(?) other platforms the stack grows downwards.
Maybe something is missing, esp. since setcontext() is involved where
a new context including stack is set and this leads to the "corrupt stack" ?

Helge



> -------- Original Message --------
> Subject: Re: Correct goarch.sh settings for gccgo on hppa?
> Date: 2022-11-26 22:17
> From: Ian Lance Taylor <iant@golang.org>
> To: matoro <matoro_mailinglist_kernel@matoro.tk>
>
> On Fri, Nov 25, 2022, 9:39 PM matoro <matoro_mailinglist_kernel@matoro.tk>
> wrote:
>
>> Oh sorry, should have clarified.  I did all those parts already, just
>> didn't include them because I assumed the at-fault piece would be in
>> goarch.sh.  This is for Linux only.
>>
>> All I did for the conditional stuff was add HPPA to all the 32-bit
>> files, and add the two unique syscall numbers.  This was based on the
>> instructions in configure.ac.  Here is the complete patch:
>> https://dpaste.com/HVHNU9BKF.txt
>>
>> Is there something I might be missing?
>>
>
>
> Good to hear you have updated the build tags.  I don't know what is wrong,
> tough.  Can you run the failing program under the debugger and find out
> where that address is coming from?
>
> But first: does a trivial hello world program work?
>
> Ian
>
>
>
> -------- Original Message --------
>> Subject: Re: Correct goarch.sh settings for gccgo on hppa?
>> Date: 2022-11-26 00:25
>>  From: Ian Lance Taylor <iant@golang.org>
>> To: matoro <matoro_mailinglist_kernel@matoro.tk>
>>
>> On Fri, Nov 25, 2022 at 8:31 PM matoro
>> <matoro_mailinglist_kernel@matoro.tk> wrote:
>> >
>> > Thank you both for the suggestions.  I tried the following values:
>> >
>> > diff --git a/libgo/goarch.sh b/libgo/goarch.sh
>> > index 977f318b3..e0d6a3ad8 100755
>> > --- a/libgo/goarch.sh
>> > +++ b/libgo/goarch.sh
>> > @@ -88,6 +88,16 @@ case $goarch in
>> >                  ;;
>> >          esac
>> >          ;;
>> > +    hppa)
>> > +       bigendian=true
>> > +       defaultphyspagesize=4096
>> > +       family=HPPA
>> > +       int64align=8
>> > +       minframesize=64
>> > +       pcquantum=4
>> > +       ptrsize=4
>> > +       stackalign=64
>> > +       ;;
>> >       ia64)
>> >          family=IA64
>> >          cachelinesize=128
>> >
>> > But unfortunately got the same result.  I wonder if there is something
>> > else missing?
>> >
>> > Ian, if you have the time, I have a machine you can use to look at
>> > this.
>>
>> As far as I know gccgo has never been ported to parisc.  This requires
>> a fair bit more than just fixing up goarch.sh.  There are a bunch of
>> files in libgo that are conditionally compiled based on the GOARCH
>> (processor) and GOOS (operating system) values.  These are marked in
>> the files by comments that start with "+build" or "go:build".  Many of
>> those comments will need to be adjusted to recognize parisc and
>> whatever operating system you are using.  If this is for HP/UX, there
>> is also operating specific code required in various places.
>>
>> I'm happy to answer questions about doing the port, but it's not a
>> trivial task.
>>
>> Ian
>>
Ian Lance Taylor Nov. 28, 2022, 8:20 p.m. UTC | #8
On Sun, Nov 27, 2022 at 12:19 AM Helge Deller <deller@gmx.de> wrote:
>
> I don't know if it's relevant, but on hppa the stack grows upwards,
> while on all(?) other platforms the stack grows downwards.
> Maybe something is missing, esp. since setcontext() is involved where
> a new context including stack is set and this leads to the "corrupt stack" ?

Interesting point and quite possibly relevant.  See the code in
runtime/stack.c.  More generally, see if the tests behave better with
the environment variable GOGC=off.  That disables the garbage
collector.

Ian
matoro Nov. 28, 2022, 9:07 p.m. UTC | #9
That seemed to do the trick!  Looks like it needs support added to 
golang.org/x/sys/unix:  https://dpaste.com/4K99E4DWH.txt

This is something I can look into on my own though.  I might come back 
to ask about the asm parts, but will try and figure it out.

So does this mean it is a GC bug?

-------- Original Message --------
Subject: Re: Correct goarch.sh settings for gccgo on hppa?
Date: 2022-11-28 15:20
 From: Ian Lance Taylor <iant@golang.org>
To: Helge Deller <deller@gmx.de>

On Sun, Nov 27, 2022 at 12:19 AM Helge Deller <deller@gmx.de> wrote:
> 
> I don't know if it's relevant, but on hppa the stack grows upwards,
> while on all(?) other platforms the stack grows downwards.
> Maybe something is missing, esp. since setcontext() is involved where
> a new context including stack is set and this leads to the "corrupt 
> stack" ?

Interesting point and quite possibly relevant.  See the code in
runtime/stack.c.  More generally, see if the tests behave better with
the environment variable GOGC=off.  That disables the garbage
collector.

Ian
Ian Lance Taylor Nov. 28, 2022, 9:24 p.m. UTC | #10
On Mon, Nov 28, 2022 at 1:07 PM matoro
<matoro_mailinglist_kernel@matoro.tk> wrote:
>
> That seemed to do the trick!  Looks like it needs support added to
> golang.org/x/sys/unix:  https://dpaste.com/4K99E4DWH.txt
>
> This is something I can look into on my own though.  I might come back
> to ask about the asm parts, but will try and figure it out.
>
> So does this mean it is a GC bug?

It's a GC bug but it's probably going to require a parisc specific
fix, likely in runtime/stack.c though possibly elsewhere as well.

Ian


> -------- Original Message --------
> Subject: Re: Correct goarch.sh settings for gccgo on hppa?
> Date: 2022-11-28 15:20
>  From: Ian Lance Taylor <iant@golang.org>
> To: Helge Deller <deller@gmx.de>
>
> On Sun, Nov 27, 2022 at 12:19 AM Helge Deller <deller@gmx.de> wrote:
> >
> > I don't know if it's relevant, but on hppa the stack grows upwards,
> > while on all(?) other platforms the stack grows downwards.
> > Maybe something is missing, esp. since setcontext() is involved where
> > a new context including stack is set and this leads to the "corrupt
> > stack" ?
>
> Interesting point and quite possibly relevant.  See the code in
> runtime/stack.c.  More generally, see if the tests behave better with
> the environment variable GOGC=off.  That disables the garbage
> collector.
>
> Ian
diff mbox series

Patch

diff --git a/libgo/goarch.sh b/libgo/goarch.sh
index 977f318b3..ed40815ac 100755
--- a/libgo/goarch.sh
+++ b/libgo/goarch.sh
@@ -88,6 +88,16 @@  case $goarch in
  		;;
  	esac
  	;;
+    hppa)
+	family=HPPA
+	bigendian=true
+	defaultphyspagesize=4096
+	minframesize=16
+	int64align=8
+	stackalign=4
+	pcquantum=4
+	ptrsize=4
+	;;
      ia64)
  	family=IA64
  	cachelinesize=128