* Correct goarch.sh settings for gccgo on hppa?
@ 2022-11-25 18:00 matoro
2022-11-25 18:31 ` Helge Deller
2022-11-25 18:45 ` John David Anglin
0 siblings, 2 replies; 11+ messages in thread
From: matoro @ 2022-11-25 18:00 UTC (permalink / raw)
To: linux-parisc; +Cc: Ian Lance Taylor, hppa
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:
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
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?
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-25 18:00 Correct goarch.sh settings for gccgo on hppa? matoro
@ 2022-11-25 18:31 ` Helge Deller
2022-11-25 18:45 ` John David Anglin
1 sibling, 0 replies; 11+ messages in thread
From: Helge Deller @ 2022-11-25 18:31 UTC (permalink / raw)
To: matoro, linux-parisc; +Cc: Ian Lance Taylor, hppa
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-25 18:00 Correct goarch.sh settings for gccgo on hppa? matoro
2022-11-25 18:31 ` Helge Deller
@ 2022-11-25 18:45 ` John David Anglin
2022-11-26 4:31 ` matoro
1 sibling, 1 reply; 11+ messages in thread
From: John David Anglin @ 2022-11-25 18:45 UTC (permalink / raw)
To: matoro, linux-parisc; +Cc: Ian Lance Taylor, hppa
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?
--
John David Anglin dave.anglin@bell.net
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-25 18:45 ` John David Anglin
@ 2022-11-26 4:31 ` matoro
2022-11-26 5:25 ` Ian Lance Taylor
0 siblings, 1 reply; 11+ messages in thread
From: matoro @ 2022-11-26 4:31 UTC (permalink / raw)
To: John David Anglin, deller; +Cc: linux-parisc, Ian Lance Taylor, hppa
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?
^ permalink raw reply related [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-26 4:31 ` matoro
@ 2022-11-26 5:25 ` Ian Lance Taylor
2022-11-26 5:39 ` matoro
0 siblings, 1 reply; 11+ messages in thread
From: Ian Lance Taylor @ 2022-11-26 5:25 UTC (permalink / raw)
To: matoro; +Cc: John David Anglin, deller, linux-parisc, hppa
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-26 5:25 ` Ian Lance Taylor
@ 2022-11-26 5:39 ` matoro
[not found] ` <CAOyqgcWK4UhU-GhEvUo26X_UEK_GK-a1xzqr27J98HAe1J9VYg@mail.gmail.com>
0 siblings, 1 reply; 11+ messages in thread
From: matoro @ 2022-11-26 5:39 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: John David Anglin, deller, linux-parisc, hppa
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
[not found] ` <CAOyqgcWK4UhU-GhEvUo26X_UEK_GK-a1xzqr27J98HAe1J9VYg@mail.gmail.com>
@ 2022-11-27 6:53 ` matoro
2022-11-27 8:19 ` Helge Deller
0 siblings, 1 reply; 11+ messages in thread
From: matoro @ 2022-11-27 6:53 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: John David Anglin, deller, linux-parisc, hppa
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
>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-27 6:53 ` matoro
@ 2022-11-27 8:19 ` Helge Deller
2022-11-28 20:20 ` Ian Lance Taylor
0 siblings, 1 reply; 11+ messages in thread
From: Helge Deller @ 2022-11-27 8:19 UTC (permalink / raw)
To: matoro, Ian Lance Taylor; +Cc: John David Anglin, linux-parisc, hppa
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
>>
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-27 8:19 ` Helge Deller
@ 2022-11-28 20:20 ` Ian Lance Taylor
2022-11-28 21:07 ` matoro
0 siblings, 1 reply; 11+ messages in thread
From: Ian Lance Taylor @ 2022-11-28 20:20 UTC (permalink / raw)
To: Helge Deller; +Cc: matoro, John David Anglin, linux-parisc, hppa
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-28 20:20 ` Ian Lance Taylor
@ 2022-11-28 21:07 ` matoro
2022-11-28 21:24 ` Ian Lance Taylor
0 siblings, 1 reply; 11+ messages in thread
From: matoro @ 2022-11-28 21:07 UTC (permalink / raw)
To: Ian Lance Taylor; +Cc: Helge Deller, John David Anglin, linux-parisc, hppa
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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: Correct goarch.sh settings for gccgo on hppa?
2022-11-28 21:07 ` matoro
@ 2022-11-28 21:24 ` Ian Lance Taylor
0 siblings, 0 replies; 11+ messages in thread
From: Ian Lance Taylor @ 2022-11-28 21:24 UTC (permalink / raw)
To: matoro; +Cc: Helge Deller, John David Anglin, linux-parisc, hppa
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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2022-11-28 21:24 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-25 18:00 Correct goarch.sh settings for gccgo on hppa? matoro
2022-11-25 18:31 ` Helge Deller
2022-11-25 18:45 ` John David Anglin
2022-11-26 4:31 ` matoro
2022-11-26 5:25 ` Ian Lance Taylor
2022-11-26 5:39 ` matoro
[not found] ` <CAOyqgcWK4UhU-GhEvUo26X_UEK_GK-a1xzqr27J98HAe1J9VYg@mail.gmail.com>
2022-11-27 6:53 ` matoro
2022-11-27 8:19 ` Helge Deller
2022-11-28 20:20 ` Ian Lance Taylor
2022-11-28 21:07 ` matoro
2022-11-28 21:24 ` Ian Lance Taylor
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.