Bug 54726 - [4.8 Regression] libbacktrace segfaults on gcc_asserts with stripped gcc
Summary: [4.8 Regression] libbacktrace segfaults on gcc_asserts with stripped gcc
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.8.0
: P1 normal
Target Milestone: 4.8.0
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-27 11:12 UTC by Markus Trippelsdorf
Modified: 2012-09-27 19:25 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Markus Trippelsdorf 2012-09-27 11:12:20 UTC
On gcc installed with "make install-strip" libbacktrace outputs
bogus "internal compiler error: Segmentation fault" on normal 
gcc_asserts.

For example the testcase from Bug 54694 now prints:

markus@x4 tmp % gcc -w -Wfatal-errors -mavx -m32 -c -O2 test.i
test.i: In function ‘helper_fldl_ST0’:
test.i:20:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.c:1532
 }
 ^
test.i:20:1: internal compiler error: Segmentation fault
gcc: internal compiler error: Segmentation fault (program cc1)
[1]    6684 segmentation fault  gcc -w -Wfatal-errors -mavx -m32 -c -O2 test.i

and this also gets logged in syslog (from dmesg):
cc1[6685]: segfault at 0 ip           (null) sp 00007fffe5fa8828 error 14 in cc1[400000+a78000]
gcc[6684]: segfault at 0 ip           (null) sp 00007fff672976b8 error 14 in gcc[400000+97000]
Comment 1 Richard Biener 2012-09-27 11:41:51 UTC
Exactly what I feared ... (Linux distributors ship stripped binaries / libraries).
Comment 2 Ian Lance Taylor 2012-09-27 15:36:30 UTC
The segfault is a bug I will fix, but the fact that the backtrace doesn't work doesn't matter.  We didn't have the backtrace information before, and we won't have it in this case either.
Comment 3 Markus Trippelsdorf 2012-09-27 15:45:05 UTC
(In reply to comment #2)
> The segfault is a bug I will fix, but the fact that the backtrace doesn't work
> doesn't matter.  We didn't have the backtrace information before, and we won't
> have it in this case either.

But gcc configures and builds libbacktrace even if one intents to strip
the gcc binaries. Therefore a configure option would be appreciated, simply
to save some build time in this case.
Comment 4 ian@gcc.gnu.org 2012-09-27 19:20:53 UTC
Author: ian
Date: Thu Sep 27 19:20:49 2012
New Revision: 191811

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191811
Log:
	PR other/54726
	* elf.c (backtrace_initialize): Set *fileln_fn, not
	state->fileln_fn.

Modified:
    trunk/libbacktrace/ChangeLog
    trunk/libbacktrace/elf.c
Comment 5 Ian Lance Taylor 2012-09-27 19:25:49 UTC
Bug fixed.

The libbacktrace library is very small compared to GCC as a whole.  I really don't think it's worth adding yet another configuration option, one that ideally would be tested but in practice would simply bitrot, merely to save the time it takes to compile 8 C files, 6 of which are very short.

There are currently only 5824 lines of C code in the entire libbacktrace library.  I really can't accept that compiling those files is a significant time penalty for somebody who is already building all of GCC.