As mentioned, this was indeed a "regression" only because of the other fix
unmasking it when before we wrongly bailed out.
The double-free and crash was due to a logic error in the failure recovery
path for declaring the CFI invalid. It would bite only when there had been
more DW_CFA_remember_state operations than DW_CFA_restore_state operations
processed at the point in the CFI program where it was diagnosed as invalid.
After fixing, that this case doesn't crash but reports:
tests/addrcfi: dwarf_addrframe (.eh_frame): no error
which is not very helpful either. But after fixing the test to fetch the
error code from the right place, it reports:
tests/addrcfi: dwarf_addrframe (.eh_frame): invalid CFI section
It's entirely possible this is as it should be. The CFI in question uses
an ill-specified sequence of operations (see my dwarf-discuss thread about
that). But, GCC has produced this sequence and it might very well be
correct to interpret it as GDB does. So I've made it handle this case in
that way rather than citing it as invalid. Now the test works and delivers
expressions for the CFA and registers.
That should make the stap case work to the extent that if it gets wrong
values now it's because that dubious CFI is actually wrong.