Ian has created a shiny libbacktrace libray which should be used to replace the current implementation in libgfortran/runtime/backtrace.c, which uses unwinder and, if available, addr2line. libbacktrace is installed both as host library (i.e. for backtraces of the compiler when an ICE occurs) and as target library, to be used by "go" and possibly other users (e.g. libgfortran). TODO: a) Enable the building of the target library: --- ./gcc/fortran/config-lang.in.orig 2011-05-10 23:12:01.000000000 +0200 +++ ./gcc/fortran/config-lang.in 2012-09-13 22:06:38.000000000 +0200 @@ -30 +30 @@ compilers="f951\$(exeext)" -target_libs=target-libgfortran +target_libs="target-libgfortran target-libbacktrace" b) Add --disable-target-libbacktrace to the toplevel configure to disable libbacktrace; e.g. for our embedded users. (toplevel implies a sync with sourceware; watch out for "go" which also uses the target library, check that "go" is still be working without target libbacktrace.) c) Configure check: Check whether the library is available. (See libgfortran/acinclude.m4's LIBGFOR_CHECK_FLOAT128 for some ideas how one can test this.) d) Configure check 2: Check whether BACKTRACE_SUPPORTED is set to 0 (-> backtrace-supported.h), in that case, it is also pointless to build the support. e) Replace the current version by calls to libbacktrace. Almost latest version of the patch: http://gcc.gnu.org/ml/gcc-patches/2012-09/msg00806.html Or wait a while and browse libbacktrace/ directly. * backtrace-supported.h contains BACKTRACE_USES_MALLOC and BACKTRACE_SUPPORTED * Available functions are listed in backtrace.h [The current version of libbacktrace only handles ELF+DWARF; one could consider keeping the other version for a while. On the other hand, I assume that other formats will soon be supported.]
You need unwind frames present for this to work, i.e. the space (and to some extent optimization-reducing - yes I'm sure) overhead of -funwind-tables. (Only x86_64 has this on, effectively.)
(In reply to comment #1) > You need unwind frames present for this to work, i.e. the space (and to some > extent optimization-reducing - yes I'm sure) overhead of -funwind-tables. (Only > x86_64 has this on, effectively.) How is this different from the current backtracing implementation in libgfortran? (That being said, we should probably modify the driver program to always add -funwind-tables, which IIRC isn't done today)
(In reply to comment #2) > (In reply to comment #1) > > You need unwind frames present for this to work, > How is this different from the current backtracing implementation in > libgfortran? Right, it already has that dependence, sorry for the noise.
I have a patch, just need to clean it up a bit and test.
Bummer, I've hit a snag. Otherwise the patch works, but trying to do a symbolic backtrace from a signal handler fails (which was sort of the entire idea of using libbacktrace instead of forking addr2line). Ian, any idea what might go wrong? With the testcase below which is expected to fail due to a div-by-zero: module test contains subroutine c(num, denum, res) integer :: num, denum, res res = num / denum end subroutine c subroutine b(n, d, r) integer :: n, d, r call c(n, d, r) end subroutine b subroutine a(n, d, r) integer :: n, d, r call b(n, d, r) end subroutine a end module test program bt use test integer :: res call a(1, 0, res) print *, res end program bt compiled with "-g" the result is $ ./bt2.g Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: Segmentation fault (core dumped) backtrace via gdb: (gdb) r Starting program: /home/janne/src/gfortran/my-patches/pr54572-libbacktrace/bt2.g Program received signal SIGFPE, Arithmetic exception. 0x000000000040086b in __test_MOD_c () (gdb) c Continuing. Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: Program received signal SIGSEGV, Segmentation fault. 0x00007ffff7bb2a1c in read_uint32 () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 (gdb) bt #0 0x00007ffff7bb2a1c in read_uint32 () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #1 0x00007ffff7bb53be in backtrace_dwarf_add () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #2 0x00007ffff7bb72a7 in elf_add () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #3 0x00007ffff7bb7696 in backtrace_initialize () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #4 0x00007ffff7bb630d in fileline_initialize () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #5 0x00007ffff7bb6427 in backtrace_pcinfo () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #6 0x00007ffff7bb6831 in unwind () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #7 0x00007ffff75b9ec9 in _Unwind_Backtrace () from /home/janne/src/gfortran/trunk/install/lib64/libgcc_s.so.1 #8 0x00007ffff7bb6885 in backtrace_full () from /home/janne/src/gfortran/trunk/install/lib64/libgfortran.so.3 #9 0x00007ffff7ad527e in _gfortrani_show_backtrace () at ../../../trunk-git/libgfortran/runtime/backtrace.c:92 #10 0x00007ffff7ad5888 in _gfortrani_backtrace_handler () at ../../../trunk-git/libgfortran/runtime/compile_options.c:129 #11 <signal handler called> #12 0x000000000040086b in __test_MOD_c () #13 0x0000000000400848 in __test_MOD_b () #14 0x000000000040081b in __test_MOD_a () #15 0x0000000000400898 in MAIN__ () #16 0x0000000000400930 in main () #17 0x00007ffff6fd176d in __libc_start_main (main=0x4008fc <main>, argc=1, ubp_av=0x7fffffffd718, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd708) at libc-start.c:226 #18 0x0000000000400709 in _start () For comparison, if I compile the testcase without "-g" then it works as expected: $ ./bt2 Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: 0x7fcf58e202a0 0x7fcf58e20887 0x7fcf5833149f 0x40086b 0x400847 0x40081a 0x400897 0x40092f 0x7fcf5831c76c 0x400708 Floating point exception (core dumped)
Created attachment 28779 [details] Patch to use libbacktrace
Why are there no line numbers in the backtrace from gdb? You said you compiled with -g. Are you sure that libbacktrace itself was compiled with -g?
The crash within libbacktrace is occurring as it tries to read the debug info. This is presumably a bug in libbacktrace, but I don't know what the problem is without more information. libbacktrace is pretty careful to only read memory that was explicitly read. There is presumably a bug there, but I don't know what it is. I doubt the fact that a signal occurred has anything to do with this. There seems to be something odd about the debug info, as shown both by the fact that libbacktrace crashes trying to read it and that gdb does not display file/line information.
(In reply to comment #7) > Why are there no line numbers in the backtrace from gdb? You said you compiled > with -g. Are you sure that libbacktrace itself was compiled with -g? I meant that I compiled the Fortran testcase with -g; GCC itself, including libbacktrace, was built with default flags which ought to be "-O2 -g", but I didn't specifically check how libbacktrace was built. Now that you mention it, it does indeed seem like libbacktrace doesn't have debug symbols for some reason. (In reply to comment #8) > The crash within libbacktrace is occurring as it tries to read the debug info. > This is presumably a bug in libbacktrace, but I don't know what the problem is > without more information. libbacktrace is pretty careful to only read memory > that was explicitly read. There is presumably a bug there, but I don't know > what it is. > > I doubt the fact that a signal occurred has anything to do with this. There > seems to be something odd about the debug info, as shown both by the fact that > libbacktrace crashes trying to read it and that gdb does not display file/line > information. I forgot to mention, that I'm able to get a symbolic backtrace from outside a signal handler. Though in that case my testcase used external procedures rather than module procedures, so I guess it's possible there's a bug in handling debug info for module procedures. I'll recheck this..
(In reply to comment #6) > Created attachment 28779 [details] > Patch to use libbacktrace I have to apply the following patch on your patch in order to be able to compile it. ("MULTIBUILDTOP" is empty here and the library is not in "/libbacktrace".) --- libgfortran-backtrace-pr54572.diff.orig 2012-11-27 10:09:13 +0100 +++ libgfortran-backtrace-pr54572.diff 2012-11-27 10:12:05 +0100 @@ -51 +51 @@ index abc23cd..dd325bd 100644 -+ -I$(MULTIBUILDTOP)/../libbacktrace \ ++ -I$(MULTIBUILDTOP)../libbacktrace \ Additionally, I wonder whether one should have: --- a/Makefile.def +++ b/Makefile.def languages = { language=fortran; gcc-check-target=check-fortran; lib-check-target=check-target-libquadmath; + lib-check-target=check-target-libbacktrace; lib-check-target=check-target-libgfortran; }; languages = { language=java; gcc-check-target=check-java; And in the same file, I wonder which of the following two is correct: +dependencies = { module=all-target-libgfortran; on=all-target-libbacktrace; }; or +dependencies = { module=configure-target-libgfortran; on=all-target-libbacktrace; };
After compiling comment 5 with my changes of comment 10, I get: Backtrace for this error: 0x2b9567c7ca0d _gfortrani_show_backtrace /projects/tob/gcc-git/gcc/libgfortran/runtime/backtrace.c:92 0x2b9567c7d017 _gfortrani_backtrace_handler /projects/tob/gcc-git/gcc/libgfortran/runtime/compile_options.c:129 0x2b95687503ef ??? ???:0 0x40086b __test_MOD_c /dev/shm/foo.f90:5 0x400847 __test_MOD_b /dev/shm/foo.f90:10 0x40081a __test_MOD_a /dev/shm/foo.f90:15 0x400897 bt /dev/shm/foo.f90:22 0x40092f main /dev/shm/foo.f90:20 And before (i.e with addr2line), I got: Backtrace for this error: #0 0x2AC1DC8D7AE7 #1 0x2AC1DC8D80F2 #2 0x2AC1DD3A43EF #3 0x40086B in __test_MOD_c at foo.f90:5 #4 0x400847 in __test_MOD_b at foo.f90:10 #5 0x40081A in __test_MOD_a at foo.f90:15 #6 0x400897 in bt at foo.f90:22
(In reply to comment #9) > (In reply to comment #7) > > Why are there no line numbers in the backtrace from gdb? You said you compiled > > with -g. Are you sure that libbacktrace itself was compiled with -g? > > I meant that I compiled the Fortran testcase with -g; GCC itself, including > libbacktrace, was built with default flags which ought to be "-O2 -g", but I > didn't specifically check how libbacktrace was built. Now that you mention it, > it does indeed seem like libbacktrace doesn't have debug symbols for some > reason. So yes, libbacktrace is compiled with debug information, however, the issue was that gdb 7.4 couldn't handle some DWARF-4 specific stuff which for some reason were generated for the libbacktrace object files (??). I upgraded to GDB 7.5, and now I get the following backtrace: (gdb) r Starting program: /home/janne/src/gfortran/my-patches/pr54572-libbacktrace/bt2.g Program received signal SIGFPE, Arithmetic exception. 0x000000000040086b in test::c (num=1, denum=0, res=32767) at bt2.f90:5 5 res = num / denum (gdb) c Continuing. Program received signal SIGFPE: Floating-point exception - erroneous arithmetic operation. Backtrace for this error: Program received signal SIGSEGV, Segmentation fault. read_uint32 (buf=buf@entry=0x7fffffffc730) at ../../../trunk-git/libbacktrace/dwarf.c:458 458 return (((uint32_t) p[3] << 24) | ((uint32_t) p[2] << 16) (gdb) bt #0 read_uint32 (buf=buf@entry=0x7fffffffc730) at ../../../trunk-git/libbacktrace/dwarf.c:458 #1 0x00007ffff7bb53be in build_address_map (addrs=0x7fffffffc710, data=0x7fffffffcf1c, error_callback=0x7ffff7ad51f0 <error_callback>, is_bigendian=0, dwarf_str_size=360, dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_ranges_size=0, dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>, dwarf_abbrev_size=253, dwarf_abbrev=0x7ffff7ff708f "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", dwarf_info_size=484, dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out of bounds>, base_address=<optimized out>, state=<optimized out>) at ../../../trunk-git/libbacktrace/dwarf.c:1299 #2 build_dwarf_data (data=0x7fffffffcf1c, error_callback=0x7ffff7ad51f0 <error_callback>, is_bigendian=0, dwarf_str_size=360, dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_ranges_size=0, dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>, dwarf_abbrev_size=253, dwarf_abbrev=0x7ffff7ff708f "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", dwarf_line_size=<optimized out>, dwarf_line=<optimized out>, dwarf_info_size=484, dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out of bounds>, base_address=<optimized out>, state=<optimized out>) at ../../../trunk-git/libbacktrace/dwarf.c:2822 #3 backtrace_dwarf_add (state=state@entry=0x7ffff7ff8000, base_address=base_address@entry=0, dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out of bounds>, dwarf_info_size=484, dwarf_line=0x7ffff7ff718c "S", dwarf_line_size=87, dwarf_abbrev=0x7ffff7ff708f "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", dwarf_abbrev_size=253, dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>, dwarf_ranges_size=0, dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_str_size=360, is_bigendian=0, error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>, data=data@entry=0x7fffffffcf1c, fileline_fn=fileline_fn@entry=0x7fffffffcb18) at ../../../trunk-git/libbacktrace/dwarf.c:2881 #4 0x00007ffff7bb72a7 in elf_add (state=state@entry=0x7ffff7ff8000, descriptor=<optimized out>, base_address=base_address@entry=0, error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>, data=data@entry=0x7fffffffcf1c, fileline_fn=fileline_fn@entry=0x7fffffffcb18, found_sym=found_sym@entry=0x7fffffffcb10, found_dwarf=found_dwarf@entry=0x7fffffffcb14) at ../../../trunk-git/libbacktrace/elf.c:757 #5 0x00007ffff7bb7696 in backtrace_initialize (state=state@entry=0x7ffff7ff8000, descriptor=<optimized out>, error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>, data=data@entry=0x7fffffffcf1c, fileline_fn=fileline_fn@entry=0x7fffffffcb98) at ../../../trunk-git/libbacktrace/elf.c:858 #6 0x00007ffff7bb630d in fileline_initialize (state=state@entry=0x7ffff7ff8000, error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>, data=data@entry=0x7fffffffcf1c) at ../../../trunk-git/libbacktrace/fileline.c:144 #7 0x00007ffff7bb6427 in backtrace_pcinfo (state=0x7ffff7ff8000, pc=140737348719229, callback=0x7ffff7ad5170 <full_callback>, error_callback=0x7ffff7ad51f0 <error_callback>, data=0x7fffffffcf1c) at ../../../trunk-git/libbacktrace/fileline.c:184 #8 0x00007ffff7bb6831 in unwind (context=<optimized out>, vdata=0x7fffffffced0) at ../../../trunk-git/libbacktrace/backtrace.c:83 #9 0x00007ffff75b9f49 in _Unwind_Backtrace (trace=trace@entry=0x7ffff7bb67e0 <unwind>, trace_argument=trace_argument@entry=0x7fffffffced0) at ../../../trunk-git/libgcc/unwind.inc:295 #10 0x00007ffff7bb6885 in backtrace_full (state=state@entry=0x7ffff7ff8000, skip=skip@entry=0, callback=callback@entry=0x7ffff7ad5170 <full_callback>, error_callback=error_callback@entry=0x7ffff7ad51f0 <error_callback>, data=data@entry=0x7fffffffcf1c) at ../../../trunk-git/libbacktrace/backtrace.c:106 #11 0x00007ffff7ad527e in _gfortrani_show_backtrace (in_signal_handler=in_signal_handler@entry=1) at ../../../trunk-git/libgfortran/runtime/backtrace.c:92 #12 0x00007ffff7ad5888 in _gfortrani_backtrace_handler (signum=8) at ../../../trunk-git/libgfortran/runtime/compile_options.c:129 #13 <signal handler called> #14 0x000000000040086b in test::c (num=1, denum=0, res=32767) at bt2.f90:5 #15 0x0000000000400848 in test::b (n=1, d=0, r=32767) at bt2.f90:10 ---Type <return> to continue, or q <return> to quit--- #16 0x000000000040081b in test::a (n=1, d=0, r=32767) at bt2.f90:15 #17 0x0000000000400898 in bt () at bt2.f90:22 #18 0x0000000000400930 in main (argc=1, argv=0x7fffffffdac1) at bt2.f90:20 #19 0x00007ffff6fd176d in __libc_start_main (main=0x4008fc <main>, argc=1, ubp_av=0x7fffffffd718, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fffffffd708) at libc-start.c:226 #20 0x0000000000400709 in _start () As an aside, my binutils is also old enough (2.22) to not handle DWARF-4 fully (e.g. addr2line doesn't understand it, objdump -W complains..), but as I understand it libbacktrace has a self-contained dwarf parser so it shouldn't matter, right? > (In reply to comment #8) > > The crash within libbacktrace is occurring as it tries to read the debug info. > > This is presumably a bug in libbacktrace, but I don't know what the problem is > > without more information. libbacktrace is pretty careful to only read memory > > that was explicitly read. There is presumably a bug there, but I don't know > > what it is. > > > > I doubt the fact that a signal occurred has anything to do with this. There > > seems to be something odd about the debug info, as shown both by the fact that > > libbacktrace crashes trying to read it and that gdb does not display file/line > > information. > > I forgot to mention, that I'm able to get a symbolic backtrace from outside a > signal handler. Though in that case my testcase used external procedures rather > than module procedures, so I guess it's possible there's a bug in handling > debug info for module procedures. I'll recheck this.. Another strange thing, if I compile the test example from #c5 with "-g -static", then it works as expected. As a summary, 1) -g => fails with backtrace above 2) -g -static => success, symbolic backtrace 3) Without -g => success, non-symbolic backtrace I'm baffled..
(In reply to comment #10) > (In reply to comment #6) > > Created attachment 28779 [details] > > Patch to use libbacktrace > > I have to apply the following patch on your patch in order to be able to > compile it. ("MULTIBUILDTOP" is empty here and the library is not in > "/libbacktrace".) > > --- libgfortran-backtrace-pr54572.diff.orig 2012-11-27 10:09:13 +0100 > +++ libgfortran-backtrace-pr54572.diff 2012-11-27 10:12:05 +0100 > @@ -51 +51 @@ index abc23cd..dd325bd 100644 > -+ -I$(MULTIBUILDTOP)/../libbacktrace \ > ++ -I$(MULTIBUILDTOP)../libbacktrace \ Good point, fixed. Also the previous line had the same issue, fixed that as well. > > > > Additionally, I wonder whether one should have: > > --- a/Makefile.def > +++ b/Makefile.def > languages = { language=fortran; gcc-check-target=check-fortran; > lib-check-target=check-target-libquadmath; > + lib-check-target=check-target-libbacktrace; > lib-check-target=check-target-libgfortran; }; > languages = { language=java; gcc-check-target=check-java; > > > > > And in the same file, I wonder which of the following two is correct: > > +dependencies = { module=all-target-libgfortran; on=all-target-libbacktrace; }; > > or > > +dependencies = { module=configure-target-libgfortran; > on=all-target-libbacktrace; }; I modeled this after how the go frontend does it. The idea, AFAICS, is that libbacktrace is always built as a hard dependency on libgfortran, however, if libbacktrace doesn't support the target, BACKTRACE_SUPPORTED is set to 0 and a dummy implementation is provided. That is, we can always unconditionally rely on libbacktrace being present. This is different from e.g. libquadmath which may or may not be available on the target, and can be explicitly enabled/disabled at configure time etc.
Thanks for the additional info. #1 0x00007ffff7bb53be in build_address_map (addrs=0x7fffffffc710, data=0x7fffffffcf1c, error_callback=0x7ffff7ad51f0 <error_callback>, is_bigendian=0, dwarf_str_size=360, dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_ranges_size=0, dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>, dwarf_abbrev_size=253, dwarf_abbrev=0x7ffff7ff708f "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", dwarf_info_size=484, dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out of bounds>, base_address=<optimized out>, state=<optimized out>) at ../../../trunk-git/libbacktrace/dwarf.c:1299 That is weird because it is showing the parameters in reverse order. Is that what gdb normally does on your system? It doesn't seem to do it for other functions. Here gdb says that the value of dwarf_info is out of bounds. That is not good. That is most likely the immediate cause of the problem. (dwarf_ranges is also out of bounds, but that likely doesn't matter as dwarf_ranges_size is zero.) It looks like it had trouble getting the debug info for the executable file itself. Can you add the output of readelf -S on the executable?
(In reply to comment #14) > Thanks for the additional info. > > #1 0x00007ffff7bb53be in build_address_map (addrs=0x7fffffffc710, > data=0x7fffffffcf1c, > error_callback=0x7ffff7ad51f0 <error_callback>, is_bigendian=0, > dwarf_str_size=360, > dwarf_str=0x7ffff7ff71e3 "integer(kind=4)", dwarf_ranges_size=0, > dwarf_ranges=0x7ffff7ff6000 <Address 0x7ffff7ff6000 out of bounds>, > dwarf_abbrev_size=253, > dwarf_abbrev=0x7ffff7ff708f > "\001\021\001%\016\023\vB\v\003\016\033\016\021\001\022\001\020\006", > dwarf_info_size=484, dwarf_info=0x7ffff7ff6eab <Address 0x7ffff7ff6eab out > of bounds>, > base_address=<optimized out>, state=<optimized out>) at > ../../../trunk-git/libbacktrace/dwarf.c:1299 > > That is weird because it is showing the parameters in reverse order. Is that > what gdb normally does on your system? It doesn't seem to do it for other > functions. No, I've never seen it before. Then again, before yesterday I had never used GDB 7.5, only older versions. > Here gdb says that the value of dwarf_info is out of bounds. That is not good. > That is most likely the immediate cause of the problem. (dwarf_ranges is also > out of bounds, but that likely doesn't matter as dwarf_ranges_size is zero.) > > It looks like it had trouble getting the debug info for the executable file > itself. Can you add the output of readelf -S on the executable? $ readelf -S bt2.g There are 35 section headers, starting at offset 0x1668: Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .interp PROGBITS 0000000000400200 00000200 000000000000001c 0000000000000000 A 0 0 1 [ 2] .note.ABI-tag NOTE 000000000040021c 0000021c 0000000000000020 0000000000000000 A 0 0 4 [ 3] .hash HASH 0000000000400240 00000240 0000000000000040 0000000000000004 A 4 0 8 [ 4] .dynsym DYNSYM 0000000000400280 00000280 0000000000000108 0000000000000018 A 5 1 8 [ 5] .dynstr STRTAB 0000000000400388 00000388 00000000000001c8 0000000000000000 A 0 0 1 [ 6] .gnu.version VERSYM 0000000000400550 00000550 0000000000000016 0000000000000002 A 4 0 2 [ 7] .gnu.version_r VERNEED 0000000000400568 00000568 0000000000000050 0000000000000000 A 5 2 8 [ 8] .rela.dyn RELA 00000000004005b8 000005b8 0000000000000018 0000000000000018 A 4 0 8 [ 9] .rela.plt RELA 00000000004005d0 000005d0 0000000000000090 0000000000000018 A 4 11 8 [10] .init PROGBITS 0000000000400660 00000660 000000000000000e 0000000000000000 AX 0 0 4 [11] .plt PROGBITS 0000000000400670 00000670 0000000000000070 0000000000000010 AX 0 0 16 [12] .text PROGBITS 00000000004006e0 000006e0 00000000000002f4 0000000000000000 AX 0 0 16 [13] .fini PROGBITS 00000000004009d4 000009d4 0000000000000009 0000000000000000 AX 0 0 4 [14] .rodata PROGBITS 00000000004009e0 000009e0 000000000000003c 0000000000000000 A 0 0 16 [15] .eh_frame_hdr PROGBITS 0000000000400a1c 00000a1c 000000000000004c 0000000000000000 A 0 0 4 [16] .eh_frame PROGBITS 0000000000400a68 00000a68 0000000000000124 0000000000000000 A 0 0 8 [17] .init_array INIT_ARRAY 0000000000600b90 00000b90 0000000000000008 0000000000000000 WA 0 0 8 [18] .fini_array FINI_ARRAY 0000000000600b98 00000b98 0000000000000008 0000000000000000 WA 0 0 8 [19] .jcr PROGBITS 0000000000600ba0 00000ba0 0000000000000008 0000000000000000 WA 0 0 8 [20] .dynamic DYNAMIC 0000000000600ba8 00000ba8 0000000000000220 0000000000000010 WA 5 0 8 [21] .got PROGBITS 0000000000600dc8 00000dc8 0000000000000008 0000000000000008 WA 0 0 8 [22] .got.plt PROGBITS 0000000000600dd0 00000dd0 0000000000000048 0000000000000008 WA 0 0 8 [23] .data PROGBITS 0000000000600e18 00000e18 0000000000000010 0000000000000000 WA 0 0 8 [24] .bss NOBITS 0000000000600e28 00000e28 0000000000000008 0000000000000000 WA 0 0 4 [25] .comment PROGBITS 0000000000000000 00000e28 0000000000000053 0000000000000001 MS 0 0 1 [26] .debug_aranges PROGBITS 0000000000000000 00000e7b 0000000000000030 0000000000000000 0 0 1 [27] .debug_info PROGBITS 0000000000000000 00000eab 00000000000001e4 0000000000000000 0 0 1 [28] .debug_abbrev PROGBITS 0000000000000000 0000108f 00000000000000fd 0000000000000000 0 0 1 [29] .debug_line PROGBITS 0000000000000000 0000118c 0000000000000057 0000000000000000 0 0 1 [30] .debug_str PROGBITS 0000000000000000 000011e3 0000000000000168 0000000000000001 MS 0 0 1 [31] .debug_loc PROGBITS 0000000000000000 0000134b 00000000000001e0 0000000000000000 0 0 1 [32] .shstrtab STRTAB 0000000000000000 0000152b 000000000000013c 0000000000000000 0 0 1 [33] .symtab SYMTAB 0000000000000000 00001f28 0000000000000768 0000000000000018 34 52 8 [34] .strtab STRTAB 0000000000000000 00002690 000000000000032d 0000000000000000 0 0 1 Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) Like I mentioned previously, my binutils is version 2.22 which apparently doesn't have complete support for DWARF-4. I can certainly try upgrading, if you think that would help; I don't really know what to look for in the above output, sorry.
Patch proposed: https://gcc.gnu.org/ml/gcc-patches/2015-08/msg00762.html
Author: fxcoudert Date: Sun Aug 23 21:50:30 2015 New Revision: 227106 URL: https://gcc.gnu.org/viewcvs?rev=227106&root=gcc&view=rev Log: PR libfortran/54572 * Makefile.def: Make libgfortran depend on libbacktrace. * Makefile.in: Regenerate. * config-lang.in: Add libbacktrace to target_libs. * Makefile.am (libgfortran_la_LDFLAGS): Link in libbacktrace. (AM_CPPFLAGS): Add libbacktrace directories to include paths. * Makefile.in: Regenerate. * aclocal.m4: Regenerate. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Remove checks for strtok_r, wait, execve, pipe, and dup2. Remove call to GCC_CHECK_UNWIND_GETIPINFO. * libgfortran.h (full_exe_path, find_addr2line, backtrace): Remove prototypes. (show_backtrace): Add prototype. * runtime/backtrace.c: Rework file entirely. * runtime/compile_options.c (backtrace_handler): Rename backtrace to show_backtrace. (maybe_find_addr2line): Remove function. (set_options): Remove call to maybe_find_addr2line. * runtime/error.c (sys_abort): Rename backtrace to show_backtrace. * runtime/main.c (store_exe_path): Empty function body. (full_exe_path, gfstrtok_r, find_addr2line): Remove functions. (cleanup): Don't free removed variables. * runtime/minimal.c (full_exe_path): Remove function. (set_args): Don't set exe_path. * gfortran.dg/backtrace_1.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/backtrace_1.f90 Modified: trunk/ChangeLog trunk/Makefile.def trunk/Makefile.in trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/config-lang.in trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/Makefile.am trunk/libgfortran/Makefile.in trunk/libgfortran/aclocal.m4 trunk/libgfortran/config.h.in trunk/libgfortran/configure trunk/libgfortran/configure.ac trunk/libgfortran/libgfortran.h trunk/libgfortran/runtime/backtrace.c trunk/libgfortran/runtime/compile_options.c trunk/libgfortran/runtime/error.c trunk/libgfortran/runtime/main.c trunk/libgfortran/runtime/minimal.c
Fixed on trunk.