https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #13 from rguenther at suse dot de 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 ian at airs dot com ---
That
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #14 from rguenther at suse dot de 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 ian at airs dot com ---
It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #8 from Andreas Schwab sch...@linux-m68k.org ---
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 #10 from Ian Lance Taylor ian at airs dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #7 from Ian Lance Taylor ian at airs dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #12 from Ian Lance Taylor ian at airs dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org ---
(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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #11 from Andreas Schwab sch...@linux-m68k.org ---
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 #5 from rguenther at suse dot de 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 ian at airs dot com ---
To
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #4 from Ian Lance Taylor ian at airs dot com ---
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 stdio.h
// void cprintln(const char *s) { puts(s); }
import
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #1 from Andreas Schwab sch...@linux-m68k.org ---
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #2 from Ian Lance Taylor ian at airs dot com ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64595
--- Comment #3 from rguenther at suse dot de 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 ian at airs dot com ---
Right,
15 matches
Mail list logo
