This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[PATCH]: Fix PR debug/19124

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?

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]