From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22330 invoked by alias); 2 Nov 2004 14:28:15 -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 22300 invoked from network); 2 Nov 2004 14:28:13 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 2 Nov 2004 14:28:13 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id iA2ES8tN028452 for ; Tue, 2 Nov 2004 09:28:08 -0500 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id iA2ES8r04995; Tue, 2 Nov 2004 09:28:08 -0500 Received: from [127.0.0.1] (localhost.localdomain [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 63725129D8C; Tue, 2 Nov 2004 09:27:34 -0500 (EST) Message-ID: <41879955.10708@gnu.org> Date: Tue, 02 Nov 2004 14:28:00 -0000 From: Andrew Cagney User-Agent: Mozilla Thunderbird 0.8 (X11/20041020) MIME-Version: 1.0 To: Mark Kettenis Cc: drow@false.org, gdb-patches@sources.redhat.com, ezannoni@redhat.com 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> <417D81D5.1000206@gnu.org> <200411012212.iA1MClCE000632@elgar.sibelius.xs4all.nl> In-Reply-To: <200411012212.iA1MClCE000632@elgar.sibelius.xs4all.nl> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-11/txt/msg00035.txt.bz2 Mark Kettenis wrote: > Date: Mon, 25 Oct 2004 18:44:37 -0400 > From: Andrew Cagney > > Thos funny little diagrams are UML isn't it? > > It needs to be changed so more like: > > SYMBOL > /|\ > | > FRAME <>----- FUNCTION <>------ UNWINDER > > and have the FUNCTION provide: > > - signal trampoline? In english: frame has-a function function has-a unwinder function is-a symbol > I think this is wrong. It's probably true that functions that are > used as signal trampolines in traditional UNIX systems are only usable > as such, this is not true for interrupt handlers. On i386 systems you > can write interrupt handlers that are also usable as trap handlers. > Where interrupt handlers are sigtramp-like, trap handlers are musch > more normal. This kind of attributes depend more on the context and > thereforeit is more logical to put them in the frame. I think the > same is true for the unwinder. > > That said, it is perfectly reasonable to let the frame inherit some of > these attributes from the function. > > Mark >