From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3427 invoked by alias); 22 May 2008 00:11:33 -0000 Received: (qmail 3417 invoked by uid 22791); 22 May 2008 00:11:32 -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; Thu, 22 May 2008 00:11:10 +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 m4M0B6pt296634 for ; Thu, 22 May 2008 00:11:06 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 m4M0B6dH1253602 for ; Thu, 22 May 2008 02:11:06 +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 m4M0B6WQ002532 for ; Thu, 22 May 2008 02:11:06 +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 m4M0B6Hj002529; Thu, 22 May 2008 02:11:06 +0200 Message-Id: <200805220011.m4M0B6Hj002529@d12av02.megacenter.de.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Thu, 22 May 2008 02:11:06 +0200 Subject: Re: [patch] Re: longjmp handling vs. glibc LD_POINTER_GUARD problems To: pedro@codesourcery.com (Pedro Alves) Date: Thu, 22 May 2008 16:29:00 -0000 From: "Ulrich Weigand" Cc: gdb-patches@sourceware.org, dan@codesourcery.com (Daniel Jacobowitz) In-Reply-To: <200805212038.02924.pedro@codesourcery.com> from "Pedro Alves" at May 21, 2008 08:38:02 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/msg00656.txt.bz2 Pedro Alves wrote: > If you're willing, could you try changing > breakpoint.c:set_longjmp_breakpoint like so? > > void > set_longjmp_breakpoint (void) > { > struct breakpoint *b; > > - if (gdbarch_get_longjmp_target_p (current_gdbarch)) > - { > create_longjmp_breakpoint ("longjmp"); > create_longjmp_breakpoint ("_longjmp"); > create_longjmp_breakpoint ("siglongjmp"); > create_longjmp_breakpoint ("_siglongjmp"); > - } > } Unfortunately this still doesn't help on s390. I think I'm running into the same type of problem you're having with you new implementation. When I get to here: 107 /* Pattern 2 - longjmp from an inner function. */ 108 if (setjmp (env) == 0) 109 { 110 call_longjmp (&env); /* patt2 */ 111 } and want to "next" over the patt2 line, GDB steps into the function and sets a step-resume breakpoint on the return address. At this point the stack pointer is (gdb) print/x $r15 $1 = 0x7fd87930 and the frame address is (gdb) info frame 0 Stack frame at 0x7fd879f8: pc = 0x400720 in main (/home/uweigand/fsf/gdb-head/gdb/testsuite/gdb.base/longjmp.c:110); saved pc 0x77df8762 source language c. Arglist at 0x7fd879f8, args: Locals at 0x7fd879f8, Previous frame's sp at 0x7fd879d4 Saved registers: r11 at 0x7fd879c4, r12 at 0x7fd879c8, r13 at 0x7fd879cc, r14 at 0x7fd879d0, pc at 0x7fd879d0 (Note that the frame address is the CFA, which is computed as stack pointer + frame size + stack bias (96 bytes) on s390.) It then catches the longjmp breakpoint, and starts stepping through. However, even with your original version using the frame_id_inner check, stepping stops at the point the stack pointer is reloaded, before we actually jump to the longjmp target: infrun: stepping through longjmp infrun: resume (step=1, signal=0), stepping_over_breakpoint=0 infrun: prepare_to_wait infrun: infwait_normal_state infrun: TARGET_WAITKIND_STOPPED infrun: stop_pc = 0x77e0dfda infrun: got out of longjmp infrun: longjmp-resume inner than step-resume infrun: step-resume breakpoint is inserted (gdb) disass 0x77e0dfda Dump of assembler code for function __longjmp: 0x77e0dfb0 <__longjmp+0>: lr %r1,%r2 0x77e0dfb2 <__longjmp+2>: ltr %r2,%r3 0x77e0dfb4 <__longjmp+4>: jne 0x77e0dfbc <__longjmp+12> 0x77e0dfb8 <__longjmp+8>: lhi %r2,1 0x77e0dfbc <__longjmp+12>: ear %r4,%a0 0x77e0dfc0 <__longjmp+16>: l %r3,20(%r4) 0x77e0dfc4 <__longjmp+20>: ld %f6,48(%r1) 0x77e0dfc8 <__longjmp+24>: ld %f4,40(%r1) 0x77e0dfcc <__longjmp+28>: lm %r6,%r13,0(%r1) 0x77e0dfd0 <__longjmp+32>: lm %r4,%r5,32(%r1) 0x77e0dfd4 <__longjmp+36>: xr %r4,%r3 0x77e0dfd6 <__longjmp+38>: xr %r5,%r3 0x77e0dfd8 <__longjmp+40>: lr %r15,%r5 <<- sets the stack pointer 0x77e0dfda <__longjmp+42>: br %r4 0x77e0dfdc <__longjmp+44>: j 0x77e0dfdc <__longjmp+44> However, at this point unwinding is broken, because the value of the stack pointer doesn't fit the status of __longjmp as frameless function as detected by prologue analysis. Breakpoint 2, 0x77e0dfda in __longjmp () from /lib/libc.so.6 (gdb) bt #0 0x77e0dfda in __longjmp () from /lib/libc.so.6 #1 0x77e0df84 in siglongjmp () from /lib/libc.so.6 #2 0x77f31000 in ?? () from /lib/libc.so.6 Cannot access memory at address 0xa7faff7c Now, even though the stack pointer was restored to the value it will have in main: (gdb) print/x $r15 $1 = 0x7fd87930 the frame address is computed under the assumption that the current function is frameless: (gdb) info frame 0 Stack frame at 0x7fd87990: pc = 0x77e0dfda in __longjmp; saved pc 0x77e0df84 called by frame at 0x7fd879f0 Arglist at 0x7fd87990, args: Locals at 0x7fd87990, Previous frame's sp in r15 Now even with the frame_id_inner check, this address counts as strictly inner to the step-resume breakpoint's frame, and thus GDB will keep going until that breakpoint is hit. Unfortunately, we have in fact bypassed that step-resume target location by the longjmp, and thus it will never hit ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com