Bug 67696 - libbacktrace prints C++ demangled name for Fortran symbol
Summary: libbacktrace prints C++ demangled name for Fortran symbol
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 5.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-23 19:09 UTC by Joost VandeVondele
Modified: 2019-06-16 08:52 UTC (History)
6 users (show)

See Also:
Host:
Target: x86_64-unknown-linux-gnu
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-10-14 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joost VandeVondele 2015-09-23 19:09:06 UTC
The backtrace printed on abort can contain demangled names, instead of the Fortran symbols. In the example below, cp__b becomes cp(bool) :

> cat test.f90
MODULE foo
CONTAINS
  SUBROUTINE cp__b()
     CALL ABORT()
  END SUBROUTINE
END MODULE 

PROGRAM test
USE foo
CALL cp__b()
END PROGRAM

> gfortran -g test.f90 ; ./a.out

Program aborted. Backtrace:
#0  0x7FE4810C6B87
#1  0x7FE4810C79C2
#2  0x7FE481198538
#3  0x4006A3 in __foo_MOD_cp(bool) at test.f90:4
#4  0x4006AC in test at test.f90:10
Aborted

I actually notice the same wrong name is printed if a backtrace is asked in gdb:

(gdb) bt
#0  0x0000003ba4a32625 in raise () from /lib64/libc.so.6
#1  0x0000003ba4a33e05 in abort () from /lib64/libc.so.6
#2  0x00007ffff7cf99a9 in _gfortrani_sys_abort () at /data/vjoost/toolchain-r15694/build/gcc-5.2.0/libgfortran/runtime/error.c:180
#3  0x00007ffff7dca539 in _gfortran_abort () at /data/vjoost/toolchain-r15694/build/gcc-5.2.0/libgfortran/intrinsics/abort.c:33
#4  0x00000000004006a4 in __foo_MOD_cp(bool) ()
#5  0x00000000004006ad in MAIN__ ()
#6  0x00000000004006e4 in main ()
#7  0x0000003ba4a1ed5d in __libc_start_main () from /lib64/libc.so.6
#8  0x00000000004005a9 in _start ()
Comment 1 Dominique d'Humieres 2015-10-13 13:23:17 UTC
On x86_64-apple-darwin14 with lldb I get

    frame #5: 0x0000000100000e95 a.out`__foo_MOD_cp__b + 14 at pr67696.f90:4
    frame #6: 0x0000000100000e9e a.out`test + 9 at pr67696.f90:10
    frame #7: 0x0000000100000ed7 a.out`main(argc=1, argv="/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out") + 54 at pr67696.f90:9

and with gdb

#5  0x0000000100000e95 in cp__b () at pr67696.f90:4
#6  0x0000000100000e9e in test () at pr67696.f90:10
#7  0x0000000100000ed7 in main (argc=1, argv=0x7fff5fbff5b0) at pr67696.f90:9
Comment 2 Joost VandeVondele 2015-10-13 13:59:36 UTC
so seemingly target specific ?
Comment 3 Dominique d'Humieres 2015-10-14 18:43:05 UTC
> so seemingly target specific ?

I forgot to say that backtrace is useless on darwin, so I got may results with gdb 7.10 and lldb 340.4.70/
Comment 4 Dominique d'Humieres 2015-10-14 18:43:29 UTC
s/may/my/
Comment 5 Tom de Vries 2019-02-10 13:47:25 UTC
The fact that the error showed up both with libbacktrace and gdb suggest that the debug information is wrong.

It would have been good to see the DW_TAG_subprogram DIE for foo (using readelf -w), with the DW_AT_name and DW_AT_linkage_name attributes. This could have confirmed that the generated debug info was incorrect.

Either way, with trunk I see:
...
 <2><126>: Abbrev Number: 5 (DW_TAG_subprogram)
    <127>   DW_AT_external    : 1
    <127>   DW_AT_name        : (indirect string, offset: 0x31a): cp__b
    <12b>   DW_AT_decl_file   : 1
    <12c>   DW_AT_decl_line   : 3
    <12d>   DW_AT_linkage_name: (indirect string, offset: 0x310): __foo_MOD_cp__b
    <131>   DW_AT_low_pc      : 0x400632
    <139>   DW_AT_high_pc     : 0xe    
    <141>   DW_AT_frame_base  : 1 byte block: 9c        (DW_OP_call_frame_cfa)
    <143>   DW_AT_GNU_all_tail_call_sites: 1
...

and:
...
Program aborted. Backtrace:
#0  0x40063f in __foo_MOD_cp__b
        at /data/gcc_versions/devel/test2.f90:4
#1  0x400648 in test
        at /data/gcc_versions/devel/test2.f90:10
#2  0x40067f in main
        at /data/gcc_versions/devel/test2.f90:9
...

So, libbacktrace prints the DW_AT_linkage_name, as is the documented behaviour.

Both the DW_AT_name and DW_AT_linkage name do not contain the 'cp(bool)' reported in comment 0.

Propose to mark this resolved-fixed.
Comment 6 Tom de Vries 2019-06-16 08:52:18 UTC
(In reply to Tom de Vries from comment #5)
> Propose to mark this resolved-fixed.

No objections, so marking this resolved-fixed.