[PATCH]: Fix PR debug/19124

[Daniel Berlin <dberlin at dberlin dot org>]

This is a 4.0 regression that is both a regression, and really a latent 
bug around for a long time (it's in 3.4, i'm not sure how far back it 
goes.  However, there is no obvious reason to backport it, as we'll see 
below)

The latent bug is that we've been generating DW_OP_fbreg forever in 
non-location-list contexts when we don't necessarily have a 
DW_AT_frame_base.  Because GDB was statically evaluating the location 
expressions and transforming them, and was transforming DW_OP_fbreg into 
a gdb expression that would look at fbreg at runtime, it worked okay, 
because it never tried to touch DW_AT_frame_base.  Thus, unless someone 
explicitly wants me to try to backport this to 3.4, i'm not going to, 
becaues it won't help anything.

The 4.0 regression deals with this in location lists.  With the location 
list infrastructure in gdb, and 4.0 it will actually evaluate 
the frame base attribute at runtime when it sees a DW_OP_fbreg in a 
location list.  When we generated a DW_OP_fbreg without a frame base, this 
would crash and burn, and actually crash gdb in the process.

The attached patch fixes the actual problem, which is that we weren't 
checking whether we had a frame base in any of our containing DIE's before 
letting loc_descriptor generate an fbreg.

In places where we don't pass around can_use_fbreg, we now default to 
*not* generating DW_OP_fbreg, and just use the actual register that it's 
representing instead (this should make no difference, in theory,
since DW_OP_fbreg should just be a space optimization, but i'm guessing 
this isn't always the case in practice).

Rather than walk the entire DIE tree up to the comp_unit_die when 
detemrining if we have a frame_base we can use, i've cut it off at 
checking up to two levels upwards.  This is because i don't have time ATM 
to do tons of compile time tests on debug info generation.  I'm happy to 
make it walk the entire DIE tree upwards (which really shouldn't be more 
than about 10 deep, even with very very heavy inlining, unless we have a 
lot of other random block dies), if we want.

I've noted this behavior in the comments of the function.

I also noticed that there was a common case we could generate a frame_base 
location and didn't, which is when we had a one element location list that 
told us where the frame register was that var-tracking had given us.  We 
don't want to output a one element location list, but certainly, if it 
tells us where the frame_base is, we should use the location to generate a 
frame_base attribute if all else fails.

Bootstrapped and regtested on i686-pc-linux-gnu.

Okay for mainline?
--Dan