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.
Thanks, Roland