From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11542 invoked by alias); 14 May 2008 21:27:31 -0000 Received: (qmail 11531 invoked by uid 22791); 14 May 2008 21:27:31 -0000 X-Spam-Check-By: sourceware.org Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net (HELO sunset.davemloft.net) (74.93.104.97) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 May 2008 21:27:13 +0000 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id F2122C8C222; Wed, 14 May 2008 14:26:58 -0700 (PDT) Date: Wed, 14 May 2008 23:03:00 -0000 Message-Id: <20080514.142658.174642357.davem@davemloft.net> To: uweigand@de.ibm.com Cc: gdb-patches@sourceware.org Subject: Re: longjmp handling vs. glibc LD_POINTER_GUARD problems From: David Miller In-Reply-To: <200805141800.m4EI0IHe006471@d12av02.megacenter.de.ibm.com> References: <200805141800.m4EI0IHe006471@d12av02.megacenter.de.ibm.com> X-Mailer: Mew version 5.2 on Emacs 22.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-IsSubscribed: yes 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-05/txt/msg00448.txt.bz2 From: "Ulrich Weigand" Date: Wed, 14 May 2008 20:00:18 +0200 (CEST) > To implement implement get_longjmp_target I'd have to retrieve > that guard value and demangle the pointers. This is of course > possible in principle -- but this assumes that the details of > where to find the guard value (typically somewhere in the > thread control block header) remain fixed across glibc versions. > I'm not sure we can actually rely on that. I couldn't find any > exported glibc mechanism to retrieve this value in a supported > way either ... I think you can treat this the same way we treat the signal frame layout. It's something undocumented but effectively fixed in stone. If glibc ever changed the offset within the thread struct for this cookie, so many binaries would break. So it is very likely the value will stay the same for the forseeable future. Thanks for pointing out this issue, I think sparc has the same problem and thus needs the same longjmp hooks.