Re: [patch] Re: longjmp handling vs. glibc LD_POINTER_GUARD problems

["Ulrich Weigand" <uweigand@de.ibm.com>]

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