Bug 1278872
| Summary: | .debug_pubnames length is too large | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Todd Allen <redhatbugzilla> | ||||||
| Component: | gcc | Assignee: | Jakub Jelinek <jakub> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Michael Petlan <mpetlan> | ||||||
| Severity: | unspecified | Docs Contact: | Tomas Capek <tcapek> | ||||||
| Priority: | unspecified | ||||||||
| Version: | 7.0 | CC: | mcermak, mnewsome, mpetlan, mpolacek, ohudlick | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | All | ||||||||
| OS: | All | ||||||||
| Whiteboard: | |||||||||
| 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 06:26:52 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 1297579, 1313485 | ||||||||
| Attachments: |
|
||||||||
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.
test fails with gcc-4.8.5-4.el7 test passes for gcc-4.8.5-9.el7 VERIFIED 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.