From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29952 invoked by alias); 3 Aug 2006 02:48:25 -0000 Received: (qmail 29930 invoked by uid 22791); 3 Aug 2006 02:48:24 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 03 Aug 2006 02:48:23 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G8TFz-0001n5-7A; Wed, 02 Aug 2006 22:48:19 -0400 Date: Thu, 03 Aug 2006 02:48:00 -0000 From: Daniel Jacobowitz To: Andi Kleen Cc: Andreas Jaeger , Mark Kettenis , gdb@sourceware.org, libc-alpha@sourceware.org Subject: Re: Notes on a frame_unwind_address_in_block problem Message-ID: <20060803024819.GA6543@nevyn.them.org> Mail-Followup-To: Andi Kleen , 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> <200608030438.18827.ak@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608030438.18827.ak@suse.de> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes 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/msg00013.txt.bz2 On Thu, Aug 03, 2006 at 04:38:18AM +0200, Andi Kleen wrote: > 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? Here's some context: http://sourceware.org/ml/gdb/2006-07/msg00131.html Basically, right now x86_64 signal delivery always uses SA_RESTORER. Glibc provides the restorer. It has some minimal, incorrect unwind information. If I remove the unwind information entirely from glibc, GDB will know how to do the right thing through a signal handler - but other unwinding scenarios like _Unwind_Backtrace won't. I can add correct unwinding information but it would know about the layout of rt_sigframe, and that's not always considered a public ABI. Alternatively, I could do this the long way: add an ELF vDSO in addition to the vsyscall pages, put syscall return trampolines there, have glibc use those if available. But I don't want to do either of those without checking with you; one is an ABI issue, the other is a huge amount more work than I was planning to do to fix the bug. > 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. Fortunately I don't have to worry about this. The vsyscall pages aren't on the signal path and if you use an old compiler to build your kernel, this will just break. Considering how long it's already been broken... But, FYI, you can't actually write the unwind tables for these using .cfi_* directives. I tried. I'd need at least three new directives to do it sanely (for uleb128 escapes, sleb128 escapes, and adding the "S" augmentation). So I did it by hand, basically copied from the i386 vDSO, but simpler since we don't need any pushes or pops. -- Daniel Jacobowitz CodeSourcery