Bug 1278872 - .debug_pubnames length is too large
.debug_pubnames length is too large
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: gcc (Show other bugs)
7.0
All All
unspecified Severity unspecified
: rc
: ---
Assigned To: Jakub Jelinek
Michael Petlan
Tomas Capek
:
Depends On:
Blocks: 1297579 1313485
  Show dependency treegraph
 
Reported: 2015-11-06 10:41 EST by Todd Allen
Modified: 2016-11-04 02:26 EDT (History)
5 users (show)

See Also:
Fixed In Version: gcc-4.8.5-6.el7
Doc Type: Bug Fix
Doc Text:
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.
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-11-04 02:26:52 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Example program (681 bytes, application/x-gzip)
2015-11-06 10:41 EST, Todd Allen
no flags Details
Patch against gcc-4.8.2 to correct the problem (706 bytes, patch)
2015-11-06 10:42 EST, Todd Allen
no flags Details | Diff


External Trackers
Tracker ID Priority Status Summary Last Updated
GNU Compiler Collection 68229 None None None Never

  None (edit)
Description Todd Allen 2015-11-06 10:41:11 EST
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.
Comment 1 Todd Allen 2015-11-06 10:42 EST
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.
Comment 6 Michael Petlan 2016-07-25 05:39:49 EDT
test fails with gcc-4.8.5-4.el7
test passes for gcc-4.8.5-9.el7

VERIFIED
Comment 8 errata-xmlrpc 2016-11-04 02:26:52 EDT
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

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