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.