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.
Prior to this update, GCC could generate too big .debug_pubnames debug section, when using the -gpubname command-line option and if there are enumeration types in the system header files. This problem has been optimized in such a way that the .debug_pubnames length is now reasonable.
Created attachment 1090710[details]
Example program
Description of problem:
When building with -gpubnames, the length value in the .debug_pubnames can be too large. It happens when the C source uses #include's of header files with enumeration types (e.g. <libio.h> via <stdio.h>).
Version-Release number of selected component (if applicable):
gcc-4.8.3-9.el7.x86_64
How reproducible:
Always
Steps to Reproduce:
1. tar zxvhf progtest.tar.gz
2. make
3.
Actual results:
The readelf of progtest.o with symbols main & variable.
The readelf of libtest.o with symbols f, i & pt.
The readelf of progtest.x with only symbols main & variable.
Expected results:
The readelf of progtest.o with symbols main & variable.
The readelf of libtest.o with symbols f, i & pt.
The readelf of progtest.x with all the above symbols: main, variable, f, i & pt.
Additional info:
The problem occurs if there are enum types in the system header files that are not marked for emission in the object file. size_of_pubnames() still counts them, but output_pubnames() does not emit them. So the size ends up being too large.
This is a big problem for dwarf readers because, when reading a linked executable, they will use the length field for the contribution from one object file to determine the location of the contribution for the next object file. If it's wrong, they can skip whole contributions and possibly (likely) end up at a random byte in the middle of some subsequent contribution.
I'll include an example. This example is small enough that the result is that the contribution from the second object file is skipped entirely and it overruns the end of the section. It would require a few more object files before there was enough material for it to end up in the middle of a subsequent contribution.
Created attachment 1090716[details]
Patch against gcc-4.8.2 to correct the problem
Yeah, the patch code is clumsy. I wrote it that way to mirror the use of a continue in output_pubnames(). It's fixed in gcc-4.9.0 by Sterling Augustine, 2013-07-25 more cleanly, but I was going for a minimal patch.
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://rhn.redhat.com/errata/RHBA-2016-2433.html
Created attachment 1090710 [details] Example program Description of problem: When building with -gpubnames, the length value in the .debug_pubnames can be too large. It happens when the C source uses #include's of header files with enumeration types (e.g. <libio.h> via <stdio.h>). Version-Release number of selected component (if applicable): gcc-4.8.3-9.el7.x86_64 How reproducible: Always Steps to Reproduce: 1. tar zxvhf progtest.tar.gz 2. make 3. Actual results: The readelf of progtest.o with symbols main & variable. The readelf of libtest.o with symbols f, i & pt. The readelf of progtest.x with only symbols main & variable. Expected results: The readelf of progtest.o with symbols main & variable. The readelf of libtest.o with symbols f, i & pt. The readelf of progtest.x with all the above symbols: main, variable, f, i & pt. Additional info: The problem occurs if there are enum types in the system header files that are not marked for emission in the object file. size_of_pubnames() still counts them, but output_pubnames() does not emit them. So the size ends up being too large. This is a big problem for dwarf readers because, when reading a linked executable, they will use the length field for the contribution from one object file to determine the location of the contribution for the next object file. If it's wrong, they can skip whole contributions and possibly (likely) end up at a random byte in the middle of some subsequent contribution. I'll include an example. This example is small enough that the result is that the contribution from the second object file is skipped entirely and it overruns the end of the section. It would require a few more object files before there was enough material for it to end up in the middle of a subsequent contribution.