From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25800 invoked by alias); 21 Nov 2008 11:40:44 -0000 Received: (qmail 25780 invoked by uid 22791); 21 Nov 2008 11:40:43 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-vbr12.xs4all.nl (HELO smtp-vbr12.xs4all.nl) (194.109.24.32) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 21 Nov 2008 11:40:03 +0000 Received: from webmail.xs4all.nl (dovemail15.xs4all.nl [194.109.26.17]) by smtp-vbr12.xs4all.nl (8.13.8/8.13.8) with ESMTP id mALBdxVk023262; Fri, 21 Nov 2008 12:39:59 +0100 (CET) (envelope-from mark.kettenis@xs4all.nl) Received: from 86.86.3.213 (SquirrelMail authenticated user sibelius) by webmail.xs4all.nl with HTTP; Fri, 21 Nov 2008 12:39:59 +0100 (CET) Message-ID: <11706.86.86.3.213.1227267599.squirrel@webmail.xs4all.nl> Date: Fri, 21 Nov 2008 19:19:00 -0000 Subject: Re: [rfc] Handle broken CFI for signal trampolines in libc on amd64-linux From: "Mark Kettenis" To: "Ulrich Weigand" , gdb-patches@sourceware.org User-Agent: SquirrelMail/1.4.11 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-11/txt/msg00580.txt.bz2 > On Fri, Nov 21, 2008 at 02:33:29AM +0100, Ulrich Weigand wrote: > > Anyway, while it is certainly good that this is fixed, I'm still > > wondering why we should rely on that when we have a hard-coded > > sigtramp detector that should be working just fine under any > > circumstances. > > I think that one reason was the extra work of the signal handler > sniffer. The amd64 one doesn't do much for named functions, though, > and functions with CFI are likely to be named. I suggest asking > Mark Kettenis's opinion. My memory is a bit hazy on this, but I think the idea was that the signal frame unwinder would only be used for older versions of linux/glibc that don't provide the necessary CFI, and that newer versions would provide correct CFI which would give the kernel/glibc people complete freedom on how to implement signal frames. As such, I'm inclined to say "no" to your diff.