From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8660 invoked by alias); 24 Jun 2004 18:10:29 -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 8633 invoked from network); 24 Jun 2004 18:10:27 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org with SMTP; 24 Jun 2004 18:10:27 -0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.10/8.12.10) with ESMTP id i5OIARe3019974 for ; Thu, 24 Jun 2004 14:10:27 -0400 Received: from localhost.redhat.com (porkchop.devel.redhat.com [172.16.58.2]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id i5OIAQ005508; Thu, 24 Jun 2004 14:10:26 -0400 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id C372F2B9D; Thu, 24 Jun 2004 14:10:14 -0400 (EDT) Message-ID: <40DB1906.3060106@gnu.org> Date: Thu, 24 Jun 2004 18:10:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-GB; rv:1.4.1) Gecko/20040217 MIME-Version: 1.0 To: Roland McGrath Cc: Mark Kettenis , drow@false.org, gdb-patches@sources.redhat.com Subject: Re: Revamp sniffer; Was: [obish?sym;rfa:doc] Wire up vsyscall References: <200406162307.i5GN7NfB025917@magilla.sf.frob.com> In-Reply-To: <200406162307.i5GN7NfB025917@magilla.sf.frob.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-06/txt/msg00514.txt.bz2 > If I understood your description correctly, the source of the current > problem scenario is that glibc supplies CFI for the trampoline code > (__restore_rt), but that CFI is not written to match how the peculiar frame > will look. So, glibc could change its CFI to use the same hack that the > x86 kernel CFI uses for the analogous code, or it could omit that CFI > entirely and expect gdb to recognize the name and/or instruction sequence. > > My inclination is to omit the CFI because that's how it is on x86 in the > analogous case. (If in future x86-64 has kernel-supplied trampoline code, > we expect it will be in the form of a vsyscall DSO that supplies CFI via > existing glibc support, as on x86. In that case, the CFI will use the same > sort of hack as the x86 CFI does.) Would that make things better? Ah! I guess it would help. GDB will still need to do something more immediate though. Andrew