From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15318 invoked by alias); 14 May 2008 18:01:20 -0000 Received: (qmail 15098 invoked by uid 22791); 14 May 2008 18:01:20 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate6.de.ibm.com (HELO mtagate6.de.ibm.com) (195.212.29.155) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 14 May 2008 18:00:56 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id m4EI0J8V093002 for ; Wed, 14 May 2008 18:00:19 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m4EI0J6d3281084 for ; Wed, 14 May 2008 20:00:19 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m4EI0Irc006474 for ; Wed, 14 May 2008 20:00:19 +0200 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with SMTP id m4EI0IHe006471 for ; Wed, 14 May 2008 20:00:18 +0200 Message-Id: <200805141800.m4EI0IHe006471@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 14 May 2008 20:00:18 +0200 Subject: longjmp handling vs. glibc LD_POINTER_GUARD problems To: gdb-patches@sourceware.org Date: Wed, 14 May 2008 18:24:00 -0000 From: "Ulrich Weigand" X-Mailer: ELM [version 2.5 PL2] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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/msg00434.txt.bz2 Hello, since the recent "stepping over longjmp" patches went in, I'm seeing test suite failures in longjmp.exp on s390, spu, and powerpc -- because none of those platforms actually implement get_longjmp_target. While I was trying to implement the missing routines, I ran into a problem: on current glibcs, the return address as stored in the jmp_buf is actually "mangled", i.e. XORed with a magic "pointer guard" value. This is apparently intended to provide some protection against buffer overflow attacks ... 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'm now wondering how we should handle this. Should be implement an ad-hoc solution to retrieve the guard, which may break in the future if glibc changes? Should we require use of LD_POINTER_GUARD=0 (which switches off the pointer guard mechanism) to enable debugging? Am I overlooking some defined interface to get at the value? Why are we using the get_longjmp_target mechanism instead of just stepping through longjmp until we see where we come out? I'd appreciate your thoughts on this ... Thanks, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com