Linux: Skip sections of type SHT_NOBITS when loading symbols.

Linux: Skip sections of type SHT_NOBITS when loading symbols.

Committed: http://code.google.com/p/google-breakpad/source/detail?r=620

[Lei Zhang (chromium)]

I get weird messages from dump_syms when reading binaries where sections exist
but have type SHT_NOBITS. We should just avoid reading them altogether.

[jimb]

On 2010/06/19 02:53:24, thestig wrote:
> I get weird messages from dump_syms when reading binaries where sections exist
> but have type SHT_NOBITS. We should just avoid reading them altogether.

What kinds of messages?  Can you provide an example executable?  (A link is
fine.)

I'm just not seeing why this should matter.

[Lei Zhang (chromium)]

On 2010/06/30 19:33:16, jimb wrote:
> On 2010/06/19 02:53:24, thestig wrote:
> > I get weird messages from dump_syms when reading binaries where sections
exist
> > but have type SHT_NOBITS. We should just avoid reading them altogether.
> 
> What kinds of messages?  Can you provide an example executable?  (A link is
> fine.)
> 
> I'm just not seeing why this should matter.

Well, what I was trying to do was run dump_syms on libc-2.7.so from Ubuntu
Hardy's libc6-dbg package. [1] If you ignore the failure in 
FindElfTextSection() and give it a dummy identifier, it would continue and try
to read the .eh_frame section, and spew a bunch of messages like:

/usr/lib/debug/lib32/libc-2.7.so: CFI entry at offset 0x0 in '.eh_frame': entry
ends early


Maybe I'm going about this the wrong way. Perhaps what we should be doing is
running dump_syms on /usr/lib32/libc-2.7.so. When dump_syms encounters a missing
section, it would check for the gnu debuglink and look for the missing section
in the debug library.

[1] http://packages.ubuntu.com/hardy/libc6-dbg

[jimb]

Let me take a step back:

It seems that GCC scrupulously avoids generating both .debug_frame and .eh_frame
data for a given .o file: since GDB can read either section, including both
would be a waste. GCC generates .eh_frame sections when exceptions are used, and
.debug_frame sections otherwise (say, for C code). Different kinds of .o files
can be linked together in an executable or library, yielding a file with both
.eh_frame and .debug_frame, although there should never be overlapping data from
those sections.

When debug information is separated, .debug_* and .stab* sections are removed
entirely from the main file, and a .gnu_debuglink is added, and all sections
other than .debug_* and .stab* are hollowed out in the debug file and turned
into SHT_NOBITS sections.  This means that .eh_frame data stays in the main
executable, while .debug_frame data goes in the debug file.

So the ideal behavior, it seems to me, is to read the main file, and read the
debug file if there is a .gnu_debuglink section.

It should be an error if we can't find the debug file; I can't see why one would
want to apply dump_syms to separated files and get silent failures if the debug
files can't be found.

Encountering any debugging section that is SHT_NOBITS should be an error, except
for .eh_frame sections in debug files. This seems like something that would be
helpful to detect and report, not silently ignore.

[Ted Mielczarek]

On 2010/07/01 06:19:56, jimb wrote:

> So the ideal behavior, it seems to me, is to read the main file, and read the
> debug file if there is a .gnu_debuglink section.

As a counterpoint, if you simply need to dump symbols for, say, system libraries
from a Linux system to have them present in your symbol store, it's a lot easier
to be able to just download the -dbg packages and dump those files than to
actually have a working install of whatever distro and install the -dbg
packages.

-Ted

[jimb]

On 2010/07/01 11:51:29, Ted Mielczarek wrote:
> As a counterpoint, if you simply need to dump symbols for, say, system
libraries
> from a Linux system to have them present in your symbol store, it's a lot
easier
> to be able to just download the -dbg packages and dump those files than to
> actually have a working install of whatever distro and install the -dbg
> packages.

To dump symbols for system libraries, one must have both the real library (for
.eh_frame) and the debug file (for everything else). dump_syms should take a
flag indicating the directory in which it should look for separated debug files;
wouldn't that make it usable in the case you describe, given only the files and
not a full running installation?

[Lei Zhang (chromium)]

On 2010/07/01 06:19:56, jimb wrote:
> Encountering any debugging section that is SHT_NOBITS should be an error,
except
> for .eh_frame sections in debug files. This seems like something that would be
> helpful to detect and report, not silently ignore.

Ok, please see patch set 2.

[jimb]

LGTM; it's better than the current behavior.

We might get warning floods, but any code that's calling that function that
often should probably be fixed anyway.