[PATCH] Force DW_CFA_def_cfa after DW_CFA_def_cfa_expression if no longer indirect

[Roland McGrath]

> For
> DW_OP_def_cfa 4 16
> DW_OP_def_cfa_expression DW_OP_breg3 32 DW_OP_deref
> DW_OP_def_cfa_register 5
> GCC producer assumes DW_OP_def_cfa 5 0, libgcc unwinder assumes DW_OP_def_cfa 5 16.
> For
> DW_OP_def_cfa 4 16
> DW_OP_def_cfa_expression DW_OP_breg3 32 DW_OP_deref
> DW_OP_def_cfa_offset 64
> GCC producer assumes DW_OP_def_cfa 3 64, libgcc unwinder assumes DW_OP_def_cfa 4 64.
> For
> DW_OP_def_cfa 4 16
> DW_OP_def_cfa_expression DW_OP_bregx 3 32 DW_OP_deref DW_OP_plus_uconst 96
> DW_OP_def_cfa_register 5
> GCC producer assumes DW_OP_def_cfa 5 96, libgcc unwinder assumes DW_OP_def_cfa 5 16.
> For
> DW_OP_def_cfa 4 16
> DW_OP_def_cfa_expression DW_OP_bregx 3 32 DW_OP_deref DW_OP_plus_uconst 96
> DW_OP_def_cfa_offset 64
> GCC producer assumes DW_OP_def_cfa 3 64, libgcc unwinder assumes DW_OP_def_cfa 4 64.

Ok.  Do I take it correctly that you're saying these situations can in
actual fact arise from the code generation GCC really does?  (And in more
than 0.66% or 10% of cases, as per the random calculus I made before?)

If that's so, then we should probably change GDB to barf rather than
faithfully calculating bogons as it has done heretofore.  Today's GDB code
assumes as you cite libgcc's unwinder assuming above.  But the one GDB will
continue for years to come to cope with output from GCCs of years past and
should do the best it can in practice.  Whereas I assume a new GCC's
version of the libgcc unwinder is not so concerned about past GCCs' code
generation (though perhaps it should be, given new libgcc_s.so's and old
executable and/or DSO binaries).


Thanks,
Roland