http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926
--- Comment #9 from dave.anglin at bell dot net 2012-12-07 13:33:16 UTC --- On 6-Dec-12, at 1:39 PM, jakub at gcc dot gnu.org wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54926 > > Jakub Jelinek <jakub at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > Status|REOPENED |WAITING > CC| |jakub at gcc dot > gnu.org > > --- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> > 2012-12-06 18:39:03 UTC --- > For the bootstrap comparison failures, I'd guess libbacktrace should > be built > with > -frandom-seed=$@ > in CFLAGS similarly how libstdc++-v3 is built. > In what way doesn't backtrace work in the compiler? Does it crash, > or not > print any backtrace? The former would be a regression, the latter > would not. > So, does: > 2012-12-06 Jakub Jelinek <ja...@redhat.com> > > PR bootstrap/54926 > * Makefile.am (AM_CFLAGS): Add -frandom-seed=$@. > * Makefile.in: Regenerated. > > --- libbacktrace/Makefile.am.jj 2012-10-02 15:36:21.000000000 +0200 > +++ libbacktrace/Makefile.am 2012-12-06 19:36:05.888001803 +0100 > @@ -34,7 +34,7 @@ ACLOCAL_AMFLAGS = -I .. -I ../config > AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \ > -I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/ > include > > -AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) > +AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) -frandom-seed=$@ > > noinst_LTLIBRARIES = libbacktrace.la > > --- libbacktrace/Makefile.in.jj 2012-10-02 15:36:21.000000000 +0200 > +++ libbacktrace/Makefile.in 2012-12-06 19:36:26.284875521 +0100 > @@ -254,7 +254,7 @@ ACLOCAL_AMFLAGS = -I .. -I ../config > AM_CPPFLAGS = -I $(top_srcdir)/../include -I $(top_srcdir)/../libgcc \ > -I ../libgcc -I ../gcc/include -I $(MULTIBUILDTOP)../../gcc/ > include > > -AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) > +AM_CFLAGS = $(EXTRA_FLAGS) $(WARN_FLAGS) $(PIC_FLAG) -frandom-seed=$@ > noinst_LTLIBRARIES = libbacktrace.la > libbacktrace_la_SOURCES = \ > backtrace.h \ > > patch fix all the regressions, turning this just into enhancement > request to > support libbacktrace better on HP-UX? The patch fixes the bootstrap comparison failure but I wouldn't say it fixes all the regressions. See attached patch. 1) The MAP_FAILED change to mmapio.c is needed to build successfully on HP-UX 10. 2) The HAVE_SYNC_FUNCTIONS change fixes an abort which regresses the handling of ICEs. The change to filename.c improves libbacktrace support on HP-UX systems using ELF binaries. With this change, I get a successful backtrace. For example, spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ /test/ gnu/gcc/gc c/gcc/testsuite/gcc.c-torture/execute/pr51447.c -fno-diagnostics-show- caret -w - O2 -lm -o /test/gnu/gcc/objdir/gcc/testsuite/gcc/pr51447.x2/test/gnu/ gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c: In function 'main':/test/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr51447.c: 27:1: internal c ompiler error: in mark_jump_label_1, at jump.c:11340x40000000005c98cf mark_jump_label_1 ../../gcc/gcc/jump.c:1134 0x40000000005c95df mark_jump_label_1 ../../gcc/gcc/jump.c:1194 0x40000000005c9347 mark_jump_label(rtx_def*, rtx_def*, int) ../../gcc/gcc/jump.c:1061 0x40000000005c9b87 mark_all_labels ../../gcc/gcc/jump.c:303 0x40000000005c9b87 rebuild_jump_labels_1 ../../gcc/gcc/jump.c:83 0x40000000005c9fb3 rebuild_jump_labels(rtx_def*) ../../gcc/gcc/jump.c:103 0x4000000000370177 cfg_layout_finalize() ../../gcc/gcc/cfgrtl.c:3805 0x4000000000a4d42f rest_of_handle_reorder_blocks ../../gcc/gcc/bb-reorder.c:2225 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. compiler exited with status 1 Possibly, the addresses could be truncated modulo 4. Adding libbacktrace support to 32-bit PA HP-UX (SOM) looks to be a much tougher. In addition, there is no equivalent to dlgetname. On HP-UX 11.11 and later, it is possible to get a path to the executable using the pstat interface. On earlier systems, a file system walk can be done but it is too slow. Think it would be better to use argv[0] with some additional checks. Dave -- John David Anglin dave.ang...@bell.net
