Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
DescriptionVIRENDRASINGH 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.
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.