Bug 2216729 - abort in GFortran 11 from GCC toolset 11 does not work with dwarf5
Summary: abort in GFortran 11 from GCC toolset 11 does not work with dwarf5
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: gcc-toolset-11-gcc
Version: 8.5
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: rc
: ---
Assignee: Marek Polacek
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-06-22 11:23 UTC by VIRENDRASINGH RAJPUT
Modified: 2023-07-10 16:06 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-07-10 16:06:05 UTC
Type: Bug
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Issue Tracker RHELPLAN-160485 0 None None None 2023-06-22 11:24:54 UTC

Description VIRENDRASINGH RAJPUT 2023-06-22 11:23:19 UTC
Description of problem: abort in GFortran 11 from GCC toolset 11 does not work with dwarf5


Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux 8.6

gcc-toolset-11-gcc-gfortran-11.2.1-9.1.el8.aarch64

How reproducible: Always



Steps to Reproduce:
1. yum install -y Package-gcc-toolset-11-gcc-gfortran-11.2.1-9.1.el8.x86_64
2. vim toto.f90
3. The "tot.f90" should look like below:

cat toto.f90 
program test_abort
  integer :: i = 1, j = 2
  if (i /= j) call abort
end program test_abort

4. Execute the below commands:
$ gfortran -o toto -O2 -g -gdwarf-5 toto.f90
$ ./toto        



Actual results:

Could not print backtrace: unrecognized DWARF version in .debug_info at 6
#0  0xffff9f46a93b
#1  0xffff9f46b58b
#2  0xffff9f5585a3
#3  0x40064f
#4  0xffff9f1e481b
#5  0x40069b
Abort(coredump)


Expected results: It should print backtrace without any issues.

With dwarf4 it works as expected
$ gfortran -o toto -O2 -g -gdwarf-4 toto.f90
$ ./toto                                    

Program aborted. Backtrace:
#0  0xffff96e5a917 in ???
#1  0xffff96e5b58b in ???
#2  0xffff96f485a3 in ???
#3  0x40064f in test_abort
	at /u/users/svc_certif/toto.f90:3
#4  0x40064f in main
	at /u/users/svc_certif/toto.f90:4
Abort(coredump)


Additional info:

We asked the customer "can you please provide some more details about the need for -gdwarf-5. Is it for some kind of certification?"

The customer confirmed as below:

"DWARF5 incorporates improvements in many areas: better data compression, separation of debugging data from executable files, improved description of macros and source files, faster searching for symbols, improved debugging of optimized code, as well as numerous improvements in functionality and performance."

We have observed most of the above improvements when using dwarf5 for our full new release code base.
Also knowing that dwarf5 was the default for GCC11 gave us more trust in this move.

Comment 1 Jakub Jelinek 2023-06-22 11:36:26 UTC
GTS GCC uses hybrid linkage model, where if system libgfortran (or libstdc++) has the same soname as the GTS GCC, then system libgfortran/libstdc++ is used plus some extra bits from static library.
This means when libgfortran is linked dynamically, support for DWARF5 unwinding has to be in the libbacktrace linked into system libgfortran.so (for RHEL8 GCC 8), which is apparently not the case.
You can use either -static-libgfortran -gdwarf-5, or -gdwarf-4, or system gfortran or GTS gfortran on RHEL9.

Comment 2 Marek Polacek 2023-07-10 16:06:05 UTC
As per Comment 1.


Note You need to log in before you can comment on or make changes to this bug.