Ian and Paul,

Could you please comment below.

Executable created with -Wl,compressed-debug-sections=zlib
using gold linker or compress debug-info via objcopy. I see problems with
local variables and backtraces in gdb.
Something like this:
gdb: bt
....
#11 0xb2356a74 in Core::WorkerImpl::WorkerThread (this=Could not find
the frame base for "Core::WorkerImpl::WorkerThread()".
)
....
Debug info is kept in separate file linked to executable
via --add-gnu-debuglink objcopy option.

Environment: gdb-weekly-CVS-7.2.50.20110125, binutils 2.21, gcc 4.4.3,
Linux, i686, 32 bit kernel 2.6.32.

IMO the problem is in
dwarf2_symbol_mark_computed function (dwarf2read.c). Check
"DW_UNSND (attr) < dwarf2_per_objfile->loc.size"
is incorrect if compressed section is used. In this case
loc.size contains compressed section size, not decompressed one.
As result large part of symbols are not passed above verification
and are left with size==0 and data==NULL after dwarf2_symbol_mark_computed
function.
The problem observed if the section has not been read via dwarf2_read_section.
But dwarf2_locate_sections has been done for the section.

The patch introduces uncompressed_size field in
struct dwarf2_section_info. And fill it in dwarf2_locate_sections.
Check in dwarf2_symbol_mark_computed function takes into
account uncompressed_size. Fields "size' and "uncompressed_size" meaning:
- "size" - section/compressed section size between dwarf2_locate_sections
and dwarf2_read_section calls. After dwarf2_read_section it is
uncompressed section size.
- "uncompressed_size" - always zero for uncompressed sections. For
compressed sections it is uncompressed section size always.

The patch is quite large cause I try to avoid code duplication
with zlib_decompress section and have to do new field initialization
properly.

Any comments are welcome

Best regards
Vladimir Simonov