From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28049 invoked by alias); 7 Nov 2004 17:36:00 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 28032 invoked from network); 7 Nov 2004 17:35:59 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 7 Nov 2004 17:35:59 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iA7HZmZH027049; Sun, 7 Nov 2004 18:35:48 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iA7HZmet032510; Sun, 7 Nov 2004 18:35:48 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iA7HZimk032505; Sun, 7 Nov 2004 18:35:44 +0100 (CET) Date: Sun, 07 Nov 2004 17:36:00 -0000 Message-Id: <200411071735.iA7HZimk032505@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sources.redhat.com, ezannoni@redhat.com, cagney@gnu.org, roland@redhat.com In-reply-to: <20041105234229.GA6082@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 5 Nov 2004 18:42:30 -0500) Subject: Re: [rfa] Attach vsyscall support for GNU/Linux References: <20041024185345.GB22700@nevyn.them.org> <200410242054.i9OKsjnl028328@elgar.sibelius.xs4all.nl> <20041024231636.GA21927@nevyn.them.org> <200410252212.i9PMCQhJ031724@elgar.sibelius.xs4all.nl> <20041101161552.GA26993@nevyn.them.org> <200411012045.iA1KjKDg000415@elgar.sibelius.xs4all.nl> <20041105234229.GA6082@nevyn.them.org> X-SW-Source: 2004-11/txt/msg00114.txt.bz2 Date: Fri, 5 Nov 2004 18:42:30 -0500 From: Daniel Jacobowitz How about this, in the meantime? If you don't like the approach, I'll wait until we can properly decide the relationship between unwinders and frame types. This patch adds a new sniffer, dwarf2_signal_frame_sniffer, which will only accept the frame if an architecture-specific hook has claimed that this is a signal frame (i386 GNU/Linux provides one that works by name). However, we then use the CFI normally - the only difference is that the result has SIGTRAMP_FRAME as its type. It works beautifully! Tested on i386-pc-linux-gnu, with vsyscall DSO. Within the current framework this seems to be a reasonable approach. Actually it's a lot less invasive than I envisioned this to be. So, actually I like it ;-). Thanks! I'm wondering though whether we need the seperate dwarf2_signal_frame_sniffer. Actually I'm sure we don't. Targets that don't want this simply shouldn't provide the signal_frame_p() function. Can you fix that? Just change dwarf2_frame_sniffer such that it checks signal_frame_p() and returns &dwarf2_sigtramp_frame_unwind instead of &dwarf2_frame_unwind if it's true. Oh, and please check the dwarf2-frame.* changes in as a seperately from the vsyscall changes. Cheers, Mark