From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4460 invoked by alias); 22 May 2008 00:14:51 -0000 Received: (qmail 4452 invoked by uid 22791); 22 May 2008 00:14:51 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate7.de.ibm.com (HELO mtagate7.de.ibm.com) (195.212.29.156) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 22 May 2008 00:14:29 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate7.de.ibm.com (8.13.8/8.13.8) with ESMTP id m4M0EPNJ394406 for ; Thu, 22 May 2008 00:14:25 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 m4M0EQwI1253428 for ; Thu, 22 May 2008 02:14:26 +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 m4M0EPKL004324 for ; Thu, 22 May 2008 02:14:25 +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 m4M0EPrT004321; Thu, 22 May 2008 02:14:25 +0200 Message-Id: <200805220014.m4M0EPrT004321@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 22 May 2008 02:14:25 +0200 Subject: Re: [patch] Re: longjmp handling vs. glibc LD_POINTER_GUARD =?iso-8859-1?q?=09problems?= To: pedro@codesourcery.com (Pedro Alves) Date: Thu, 22 May 2008 16:38:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, dan@codesourcery.com (Daniel Jacobowitz) In-Reply-To: <200805212339.50247.pedro@codesourcery.com> from "Pedro Alves" at May 21, 2008 11:39:49 PM 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/msg00657.txt.bz2 Pedro Alves wrote: > Seeing this, I was thinking of: > - recording the longjmp frame when the longjmp breakpoint is hit > - single-step until the longjmp frame is gone (going to return to setjmp -- > SP/FP changing) > - single-step until this new current frame is gone. During the time longjmp reloads the registers, I now don't think we can trust the frame at all; this is even worse that during regular function epilogues. I think one heuristics might be that as soon as we notice odd things to happen to the frame, we step until we reach the end of the current *function* (i.e. look only at the PC). > But, x86 doesn't show any promise on that... The first time > we stop seeing the longjmp frame on the frame stack is much > earlier than the exit of longjmp: > > #0 0xf7e201d8 in ?? () from /lib32/libc.so.6 > #1 0x00000001 in ?? () So what's happening there? Is this some unrelated unwinder failure? Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com