https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #14 from rguenther at suse dot de ---
On Tue, 20 Jan 2015, ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
>
> --- Comment #12 from Ian Lance Taylor ---
> It's not libbacktrace that is crashing the a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #13 from rguenther at suse dot de ---
On Mon, 19 Jan 2015, ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
>
> --- Comment #7 from Ian Lance Taylor ---
> That failure is not related to the new gotool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #12 from Ian Lance Taylor ---
It's not libbacktrace that is crashing the app, it's libgo.
And, yes, probably libgo should not crash the app either. But it's also true
that many Go programs simply won't work correctly if file/line in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #11 from Andreas Schwab ---
But it shouldn't crash the app if you don't have the full information.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #10 from Ian Lance Taylor ---
The point of libbacktrace, at least if you call the backtrace_full function, is
to get file/line information. If you don't need file/line information, you can
just use _Unwind_Backtrace.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #9 from Andrew Pinski ---
(In reply to Andreas Schwab from comment #8)
> Why does libbacktrace need debug info? All required unwind information is
> included in the binary. Glibc's backtrace can do that too.
Most likely the same re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #8 from Andreas Schwab ---
Why does libbacktrace need debug info? All required unwind information is
included in the binary. Glibc's backtrace can do that too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #7 from Ian Lance Taylor ---
That failure is not related to the new gotools. I expect it would happen with
any Go program. Go requires that there be enough debug info to do a stack
backtrace with file/line information. It uses the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #6 from Richard Biener ---
The backtrace is
Breakpoint 1, __GI_exit (status=4) at exit.c:104
104 exit.c: No such file or directory.
(gdb) up
#1 0x7731a52f in runtime_startpanic () from /usr/lib64/libgo.so.7
(gdb)
#2 0x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #5 from rguenther at suse dot de ---
On Wed, 14 Jan 2015, ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
>
> --- Comment #4 from Ian Lance Taylor ---
> To invoke cgo, put this code in a file foo.go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #4 from Ian Lance Taylor ---
To invoke cgo, put this code in a file foo.go and type "go run foo.go" (or "go
build foo.go && ./foo").
package main
// #include
// void cprintln(const char *s) { puts(s); }
import "C"
func main() {
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #3 from rguenther at suse dot de ---
On Wed, 14 Jan 2015, ian at airs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
>
> --- Comment #2 from Ian Lance Taylor ---
> Right, cgo is not run directly. It is run by
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #2 from Ian Lance Taylor ---
Right, cgo is not run directly. It is run by the go tool. It is in effect an
internal program like cc1.
The version suffix should be fine if libexecsubdir in libgo matches
libexecsubdir in gotools, as t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #1 from Andreas Schwab ---
According to http://golang.org/cmd/cgo/ cgo isn't supposed to be called
directly, but only via go tool cgo. But the version suffix will probably break
it.
15 matches
Mail list logo
