From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27020 invoked by alias); 27 Dec 2005 04:24:35 -0000 Received: (qmail 27012 invoked by uid 22791); 27 Dec 2005 04:24:34 -0000 X-Spam-Check-By: sourceware.org Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.203) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 27 Dec 2005 04:24:32 +0000 Received: by zproxy.gmail.com with SMTP id x3so1306722nzd for ; Mon, 26 Dec 2005 20:24:31 -0800 (PST) Received: by 10.36.18.17 with SMTP id 17mr3922677nzr; Mon, 26 Dec 2005 20:24:30 -0800 (PST) Received: by 10.37.2.42 with HTTP; Mon, 26 Dec 2005 20:24:30 -0800 (PST) Message-ID: <8f2776cb0512262024n39deb5e9q64ab62c48652e336@mail.gmail.com> Date: Tue, 27 Dec 2005 04:24:00 -0000 From: Jim Blandy To: Eli Zaretskii Subject: Re: Stepping over longjmp presumably broken for glibc Cc: gdb@sourceware.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <20051222211734.GA13178@nevyn.them.org> <20051223152021.GA26794@nevyn.them.org> <20051223170913.GA28791@nevyn.them.org> <20051224162302.GA11929@nevyn.them.org> <8f2776cb0512252006i4b28abe7if0fd67dd8cee6f10@mail.gmail.com> X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2005-12/txt/msg00203.txt.bz2 On 12/25/05, Eli Zaretskii 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.