From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10644 invoked by alias); 3 Aug 2006 02:38:37 -0000 Received: (qmail 10625 invoked by uid 22791); 3 Aug 2006 02:38:36 -0000 X-Spam-Check-By: sourceware.org Received: from ns.suse.de (HELO mx1.suse.de) (195.135.220.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 03 Aug 2006 02:38:34 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 2913AF520; Thu, 3 Aug 2006 04:38:32 +0200 (CEST) From: Andi Kleen To: Daniel Jacobowitz Subject: Re: Notes on a frame_unwind_address_in_block problem Date: Thu, 03 Aug 2006 02:38:00 -0000 User-Agent: KMail/1.9.3 Cc: Andreas Jaeger , Mark Kettenis , gdb@sourceware.org, libc-alpha@sourceware.org References: <20060706222157.GA1377@nevyn.them.org> <20060718183520.GA17864@nevyn.them.org> <20060803020423.GA5693@nevyn.them.org> In-Reply-To: <20060803020423.GA5693@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608030438.18827.ak@suse.de> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-08/txt/msg00012.txt.bz2 On Thursday 03 August 2006 04:04, Daniel Jacobowitz wrote: > On Tue, Jul 18, 2006 at 02:35:20PM -0400, Daniel Jacobowitz wrote: > > The only caveat is that it is in glibc, but knows about the kernel > > layout of struct rt_sigframe - specifically that a struct ucontext > > lives just above the SA_RESTORER return address. Andi, what do you > > think of that? If it's a bad idea, we may need a different approach > > (i.e. a vdso). Missing context a bit. What exactly is the problem? > Andreas, Andi, did either of you have an opinion on this? I'd really > like to get the "GDB bug" fixed one way or the other. But I'm not > sure yet if we can do it with this glibc patch, or whether we need a > true ELF vDSO - or what other x86_64 specific issues that might have. We'll get a vDSO with kernel supplied unwind sectins sooner or later, but you'll have to handle the old vsyscall without unwinding anyways because it's not going to go away. Also even the vDSO might end up without unwind information when compiled with old compilers because I don't plan to support it without .cfi_* support in binutils. -Andi