From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15506 invoked by alias); 16 Jun 2004 23:07:44 -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 15438 invoked from network); 16 Jun 2004 23:07:31 -0000 Received: from unknown (HELO gateway.sf.frob.com) (64.81.54.130) by sourceware.org with SMTP; 16 Jun 2004 23:07:31 -0000 Received: from magilla.sf.frob.com (magilla.sf.frob.com [198.49.250.228]) by gateway.sf.frob.com (Postfix) with ESMTP id D5BA4357B; Wed, 16 Jun 2004 16:07:26 -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 i5GN7POi025921; Wed, 16 Jun 2004 16:07:26 -0700 Received: (from roland@localhost) by magilla.sf.frob.com (8.12.9/8.12.9/Submit) id i5GN7NfB025917; Wed, 16 Jun 2004 16:07:23 -0700 Date: Wed, 16 Jun 2004 23:07:00 -0000 Message-Id: <200406162307.i5GN7NfB025917@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 Tuesday, 15 June 2004 16:16:53 -0400 <40CF5935.70007@gnu.org> Emacs: if SIGINT doesn't work, try a tranquilizer. X-SW-Source: 2004-06/txt/msg00393.txt.bz2 I don't have all the background on gdb internals here, but I think I understand what you've described. On the x86, the same issue has been considered. The signal trampoline code provided by the kernel in the vsyscall DSO (which is what gets used with current glibc on kernels supporting it) has CFI that starts one byte before the actual trampoline code. This comment is from the arch/i386/kernel/vsyscall-sigreturn.S, which supplies the handwritten CFI data in Linux 2.6 kernels: /* HACK: The dwarf2 unwind routines will subtract 1 from the return address to get an address in the middle of the presumed call instruction. Since we didn't get here via a call, we need to include the nop before the real start to make up for it. */ In the x86-64 case, there is no kernel-supplied trampoline and current glibc supplies one and gives it CFI. OTOH, on the x86 on kernels that do not supply the vsyscall DSO, glibc supplies the trampoline and it provides no CFI for it, so whatever traditional name-matching or disassembly magic gdb does takes place instead. 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? Thanks, Roland