Re: Stepping over longjmp presumably broken for glibc

[Jim Blandy <jimb@red-bean.com>]

On 12/25/05, Eli Zaretskii <eliz@gnu.org> wrote:
> My point was that we already depend on all kinds of ad-hoc knowledge
> of the ABI and the runtime, so adding one more dependency would not
> hurt too much, although I'd applaud to changes to do that without any
> such dependencies.

I think Daniel's intent was to solicit ideas, indicating what sort of
ideas he prefers.  It sounds like you agree with his preference, but
don't have any qualifying ideas.  Daniel's posts don't give me the
impression that he minds using ad-hoc information when there's no
alternative.

Here's my (non-qualifying because it relies on help from the runtime)
idea: can't we use Dwarf CFI here?  That is, treat longjmp as a weird
function whose CFI indicates that it unwinds to the setjmp.  The
DW_CFA_val_expression operator, new in the released Dwarf 3 spec,
allows CFI to use an arbitrary expression to compute the saved value
of the register; we can apply that to the return address column just
as well as anything else.  In the case Daniel described, the
expression would use DW_OP_xor (probably the first use ever of that
opcode!).

Dwarf 3 Draft 9.7, Section 6.4.1:
...
The register rules are:
...
val_expression(E) The previous value of this register is the value
produced by executing the DWARF expression E.

Section 6.4.2:
...
21. DW_CFA_val_expression

    The DW_CFA_val_expression instruction takes two operands: an
unsigned LEB128 value representing a register number, and a
DW_FORM_block value representing a DWARF expression. The required
action is to change the rule for the register indicated by the
register number to be a val_expression(E) rule where E is the DWARF
expression. That is, the DWARF expression computes the value of the
given register. The value of the CFA is pushed on the DWARF evaluation
stack prior to execution of the DWARF expression.

The DW_OP_call2, DW_OP_call4, DW_OP_call_ref and
DW_OP_push_object_address DWARF operators (see Section 2.5.1) cannot
be used in such a DWARF expression.