Launchpad has imported 13 comments from the remote bug at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368.

If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.

------------------------------------------------------------------------
On 2015-06-01T21:27:03+00:00 Doko-v wrote:

"go version" on powerpc-linux-gnu works with the 5.1 release candidate,
but crashes with the 5.1.0 release, and the current branch.

reverting the changes made in PR65787 fixes the issue. Seen on Ubuntu
15.04 and 15.10 systems, however I can't reproduce this in Debian
unstable. Same binutils version, Debian has glibc-2.19, Ubuntu
glibc-2.21.  It looks like I can't reproduce this with a GCC trunk build
on either platform. So I'm a bit lost ...

$ go version
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

goroutine 0 [idle]:
panic during panic

goroutine 0 [idle]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_startpanic
        ../../../src/libgo/runtime/panic.c:100
runtime_throw
        ../../../src/libgo/runtime/panic.c:191
runtime_gogo
        ../../../src/libgo/runtime/proc.c:251
runtime_tracebackothers
        ../../../src/libgo/runtime/proc.c:767
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:139
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/5

------------------------------------------------------------------------
On 2015-06-01T23:00:29+00:00 Doko-v wrote:

correction: reverting the changes from PR65787 only helps for the 5.1.0
release, not the gcc-5-branch.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/6

------------------------------------------------------------------------
On 2015-06-02T16:28:35+00:00 Doko-v wrote:

maybe the changes from PR65787 are unrelated.

Building a compiler which has -fstack-protector strong enabled by
default. The crash goes away when I add -fno-stack-protector to
AM_CFLAGS in libgo.  So it should be reproducible by adding -fstack-
protector strong to AM_CFLAGS in libgo.

Don't know why this shows up only now, and on powerpc-linux-gnu only.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/7

------------------------------------------------------------------------
On 2015-06-02T17:11:39+00:00 Boger-e wrote:

Let's get the obvious set up questions out of the way first...

If you are building on Ubuntu, I assume you must be trying to build
powerpc64le-linux-gnu, and not powerpc-linux-gnu.

Is your LD_LIBRARY_PATH being set to the correct path for the libgo that
corresponds to the go and gccgo you are using?  That is, you aren't
using libgo from a gcc trunk build but go and gccgo from a gcc5 build?

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/8

------------------------------------------------------------------------
On 2015-06-02T20:44:22+00:00 Adam Conrad wrote:

No, this is specifically about powerpc-linux-gnu.  powerpc64le works
fine.

As for the library path questions, this first came up in runtime bug
reports, and has been confirmed by many on clean chroots, so no, there
aren't random libraries kicking around from other builds.

doko's stack-protector discovery makes perfect sense as to why this
works fine on Debian but not Ubuntu, as that's really the only
difference between our two toolchains.  Now, the question is *why*, and
why only on ppc32?  (Or maybe only on big-endian PPC, neither of us has
tested a powerpc64-linux-gnu build yet).

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/9

------------------------------------------------------------------------
On 2015-06-02T22:37:21+00:00 Doko-v wrote:

building trunk libgo with -fstack-protector-strong yields:

$ go version
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:

        :0

        :0

        :0

        :0
[...]

building libgo and libbacktrace with -fstack-protector-strong yields:

fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0x3]

goroutine 16 [running]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

goroutine 0 [idle]:
panic during panic
goroutine 0 [idle]:
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:131
runtime_startpanic
        ../../../src/libgo/runtime/panic.c:100
runtime_throw
        ../../../src/libgo/runtime/panic.c:191
runtime_gogo
        ../../../src/libgo/runtime/proc.c:251
runtime_tracebackothers
        ../../../src/libgo/runtime/proc.c:767
runtime_dopanic
        ../../../src/libgo/runtime/panic.c:139
runtime_throw
        ../../../src/libgo/runtime/panic.c:193
sig_panic_leadin
        ../../../src/libgo/runtime/go-signal.c:247
sig_panic_info_handler
        ../../../src/libgo/runtime/go-signal.c:281

        :0
__go_go
        ../../../src/libgo/runtime/proc.c:2328
runtime_main
        ../../../src/libgo/runtime/proc.c:598

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/10

------------------------------------------------------------------------
On 2015-06-03T13:08:13+00:00 Boger-e wrote:

I think you've said the problem only occurs when using -fstack-
protector-strong and when building with glibc-2.21.

Have you tried using gdb to see where the segv actually occurs?

>gdb go
.....


>run version
(Once it hits the segv)
>x/20ni $pc-24
>bt

The panic stacktrace is showing a line in proc.c:2328 which is making a
call to __builtin_return_address according to my source.  Does that
match your source?

If that is the case then I have a feeling this isn't go specific, but a
problem with calling __builtin_return_address on ppc32 when using
-fstack-protector-strong and possibly glibc-2.21 has some affect.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/11

------------------------------------------------------------------------
On 2015-06-04T03:26:09+00:00 Wschmidt-f wrote:

FYI, PR65787 only changes behavior for powerpc64le, so it's odd that you
would see any differences with or without those changes.  The two
patched routines are never called for big endian.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/13

------------------------------------------------------------------------
On 2015-07-16T09:11:36+00:00 Rguenth wrote:

GCC 5.2 is being released, adjusting target milestone to 5.3.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/14

------------------------------------------------------------------------
On 2015-11-23T04:12:24+00:00 Ian Lance Taylor wrote:

I'm not having any luck reproducing this.  I built a 32-bit PPC
GNU/Linux (on the GCC compile farm, which is a PPC64 machine, using
glibc 2.18).  I deleted the libgo files and rebuilt them with -fstack-
protector-strong.  I built a new go tool.  It seems to work fine.

Let's try this: if you can still recreate this problem, send me the
crashing binary.  Maybe I can see something there.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/15

------------------------------------------------------------------------
On 2015-12-04T10:43:55+00:00 Rguenth wrote:

GCC 5.3 is being released, adjusting target milestone.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/16

------------------------------------------------------------------------
On 2016-06-03T10:04:35+00:00 Rguenth wrote:

GCC 5.4 is being released, adjusting target milestone.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/17

------------------------------------------------------------------------
On 2022-01-09T00:56:54+00:00 Pinskia wrote:

No feedback in over 6 years so closing.

Reply at:
https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1454183/comments/18


** Changed in: gcc
       Status: Incomplete => Invalid

-- 
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1454183

Title:
  gccgo crash on powerpc

To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/1454183/+subscriptions


-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to