From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19848 invoked by alias); 3 Aug 2006 03:21:42 -0000 Received: (qmail 19832 invoked by uid 22791); 3 Aug 2006 03:21:42 -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 03:21:40 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1G8TmC-00020v-GO; Wed, 02 Aug 2006 23:21:36 -0400 Date: Thu, 03 Aug 2006 03:21: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: <20060803032136.GA7647@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> <200608030438.18827.ak@suse.de> <20060803024819.GA6543@nevyn.them.org> <200608030511.46390.ak@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200608030511.46390.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/msg00015.txt.bz2 On Thu, Aug 03, 2006 at 05:11:46AM +0200, Andi Kleen wrote: > 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. I figured you'd do what i386 did - if SA_RESTORER isn't set, use a trampoline in the vDSO. > > 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. Good enough for me. Andreas, in that case, is the patch in http://sourceware.org/ml/gdb/2006-07/msg00131.html OK? > > 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. I'm confused now. x86-64 doesn't have signal trmapolines in its vsyscall pages, unless they've been added in the last week or two. The only vsyscalls on x86-64 are vgettimeofday and vtime, in the git pull I've got here. > > 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. Not being able to annotate them correctly would suck. Roland (I think) did the hard work of describing them correctly; given the macros and comments he used, I think it's pretty straightforward. It would be possible to add the necessary bits to gas, but I wouldn't hold my breath. There was a third problem other than the two I mentioned above but I'm afraid I can't remember what it was now. I'd have to try it again. I did work around both the uleb128 and sleb128 problems, and there's actually a signal frame marker in sufficiently recent gas, but I ran into another problem that made me give up. -- Daniel Jacobowitz CodeSourcery