From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15605 invoked by alias); 3 Aug 2006 03:12:12 -0000 Received: (qmail 15589 invoked by uid 22791); 3 Aug 2006 03:12:11 -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 03:12:08 +0000 Received: from Relay1.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 E53B0F8F2; Thu, 3 Aug 2006 05:12:05 +0200 (CEST) From: Andi Kleen To: Daniel Jacobowitz Subject: Re: Notes on a frame_unwind_address_in_block problem Date: Thu, 03 Aug 2006 03:12: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> <200608030438.18827.ak@suse.de> <20060803024819.GA6543@nevyn.them.org> In-Reply-To: <20060803024819.GA6543@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200608030511.46390.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/msg00014.txt.bz2 On Thursday 03 August 2006 04:48, Daniel Jacobowitz wrote: > Basically, right now x86_64 signal delivery always uses SA_RESTORER. It will always. The kernel errors out if SA_RESTORER is not set. > 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. in practice it is - lots of programs assume it. I guess it's the best you can do for now. > 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. I plan to add a vDSO myself. > > 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 The signal trampolines are in the vsyscall pages. x86-64 doesn't actually have a gate page like i386. > 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. If it's not possible to do sanely there won't be any unwind annotation. I refuse to deal with any more of this binary mess that the compat vsyscalls use because it's imho totally unmaintainable. -Andi