From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19079 invoked by alias); 24 Jun 2004 20:59:09 -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 19067 invoked from network); 24 Jun 2004 20:59:08 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sourceware.org with SMTP; 24 Jun 2004 20:59:08 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id 1EAA5357B; Thu, 24 Jun 2004 13:59:07 -0700 (PDT) Received: from magilla.sf.frob.com (localhost.localdomain [127.0.0.1]) by magilla.sf.frob.com (8.12.9/8.12.9) with ESMTP id i5OKx6Oi001996; Thu, 24 Jun 2004 13:59:06 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i5OKx48V001992; Thu, 24 Jun 2004 13:59:04 -0700 Date: Thu, 24 Jun 2004 20:59:00 -0000 Message-Id: <200406242059.i5OKx48V001992@magilla.sf.frob.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: Andrew Cagney Cc: Mark Kettenis , drow@false.org, gdb-patches@sources.redhat.com Subject: Re: Revamp sniffer; Was: [obish?sym;rfa:doc] Wire up vsyscall In-Reply-To: Andrew Cagney's message of Thursday, 24 June 2004 14:10:14 -0400 <40DB1906.3060106@gnu.org> X-Windows: more than enough rope. X-SW-Source: 2004-06/txt/msg00523.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. I guess it can do the magic name-matching first and ignore CFI if it matches, but I don't really have anything to add to the gdb part of the discussion. Which change would gdb people prefer in glibc? No CFI, or CFI that is fixed with the kludge to match one byte before the entry point? Thanks, Roland