I ran into a SEGV in in gdb-7.2 in dwarf_expr_eval() (actually one of the
functions it calls) which is called from dwarf2_evaluate_loc_desc_full().
This was caused by the per_cu->cu==NULL.

The circumstances which triggered this SEGV is printing a huge structure
(four or five pages of output) followed by a backtrace.  While printing
the struct, dwarf2_fetch_die_location_block() is called multiple times,
which calls age_cached_comp_units() which removes CU data from the cache.
When doing the backtrace, location descriptions are referenced and eventually
a NULL per_cu->cu is dereferenced.

I created the attached patch fixes the problem in gdb-7.2 by adding a new
function dwarf2_read_comp_unit_if_needed() which reloads the CU data and
adds it to the cache.  I also modified dwarf2_per_cu_addr_size() and
dwarf2_per_cu_addr_size() to use this function rather than read the CU
header into a temporary.

When I tried to apply this to the head, I discovered that these functions
had been refactored adding a function per_cu_header_read_in() which read
in the CU header into a temporary.

I can rework the patch to exclude the conflicting changes, but this raises
a question:  Is there a reason to read the CU header into a temporary data
area rather than reload it using load_full_comp_unit() which will add it to
the CU cache?

I noticed that a TRY_CATCH was added to dwarf2_evaluate_loc_desc_full()
which would catch this SEGV, but (it seems to me, incorrectly) indicate that
debug data was not available.

-- 
Michael Eager	 eager@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077