From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29626 invoked by alias); 17 Jul 2006 07:30:01 -0000 Received: (qmail 29591 invoked by uid 22791); 17 Jul 2006 07:30:00 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-vbr2.xs4all.nl (HELO smtp-vbr2.xs4all.nl) (194.109.24.22) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 17 Jul 2006 07:29:57 +0000 Received: from webmail.xs4all.nl (dovemail4.xs4all.nl [194.109.26.6]) by smtp-vbr2.xs4all.nl (8.13.6/8.13.6) with ESMTP id k6H7TklX082648; Mon, 17 Jul 2006 09:29:46 +0200 (CEST) (envelope-from mark.kettenis@xs4all.nl) Received: from 192.87.1.22 (SquirrelMail authenticated user sibelius) by webmail.xs4all.nl with HTTP; Mon, 17 Jul 2006 09:29:46 +0200 (CEST) Message-ID: <8340.192.87.1.22.1153121386.squirrel@webmail.xs4all.nl> In-Reply-To: References: <20060706222157.GA1377@nevyn.them.org> <200607132020.k6DKKCSB023812@elgar.sibelius.xs4all.nl> Date: Mon, 17 Jul 2006 13:15:00 -0000 Subject: Re: Notes on a frame_unwind_address_in_block problem From: "Mark Kettenis" To: "Andreas Jaeger" Cc: "Mark Kettenis" , drow@false.org, gdb@sourceware.org, libc-alpha@sourceware.org User-Agent: SquirrelMail/1.4.5 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit 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-07/txt/msg00112.txt.bz2 > Mark Kettenis writes: > > > [...] > > Looking at sysdeps/unix/sysv/linux/x86_64/sigaction.c in the glibc > > sources: > > > > asm \ > > ( \ > > ".align 16\n" \ > > CFI_STARTPROC "\n" \ > > "__" #name ":\n" \ > > " movq $" #syscall ", %rax\n" \ > > " syscall\n" \ > > CFI_ENDPROC "\n" \ > > ); > > > > Someone should either add the proper unwind info or remove the unwind > > info altogether. > > What do you suggest to add here? Something like what's done in the kernel (arch/x86_64/kernel/vsyscall.S). Hmm, I wonder why Daniel's box uses the trampoline from libc instead of the trampoline in the vsyscall page. Looking a bit closer, it seems my amd64 machine here at work has the same issue (SuSE 9.2 with a 2.6.8-24.20 kernel and glibc 2.3.3). Is it just my glibc that's out of date, or is something busted? Anyway, if with the current libc, the trampoline provided by the kernel is supposed to be used, then it's probably not worth bothering to add CFI to libc, and I'd just remove the CFI_STARTPROC and CFI_ENDPROC statements. Mark