A Wednesday 21 May 2008 20:38:02, Pedro Alves wrote:
> A Wednesday 21 May 2008 20:20:19, Ulrich Weigand wrote:
>
> > Another issue with your patch is the use of frame_id_inner ... I'd rather
> > get rid of this function instead of adding new uses, because this really
> > requires that it is possible to compare two stack (frame) addresses
> > along a linear order.  This breaks for me in multi-architecture
> > scenarios, but even on existing targets it may not always work OK (e.g.
> > if signal handlers run on a different frame, or if the code uses some
> > sort of user-level threading or coroutine library ...).  Maybe instead of
> > comparing frame_ids, it would be better to check whether or not a frame
> > with the given ID still exists in the current backtrace?

> OK.  That may work too.  I'll give it a try.

Hmmm, I got blocked getting that to work.  It always stops stepping
before getting to the other side.  It looks like going out of
longjmp, the frame id of the longjmp's caller starts
being computed differently, or badly...

Using the longjmp.c testcase, on x86_64:

(gdb) n
99            longjmp (env, 1); /* patt1 */
(gdb) n

(about thirty or so single-steps go ok, but then it stops,)

0x00007f0480e4af33 in ?? () from /lib/libc.so.6
(gdb) bt
#0  0x00007f413d0dff33 in ?? () from /lib/libc.so.6
#1  0x000000000040067d in main () 
at ../../../src/gdb/testsuite/gdb.base/longjmp.c:96

(gdb) disassemble ($pc-20)  ($pc + 28)
Dump of assembler code from 0x7f26b04fbf1f to 0x7f26b04fbf4f:
0x00007f26b04fbf1f:     xor    0x30,%ecx
0x00007f26b04fbf26:     ror    $0x11,%rdx     << look, pointer unmangling!
0x00007f26b04fbf2a:     xor    %fs:0x30,%rdx  <<    "        "
0x00007f26b04fbf33:     mov    (%rdi),%rbx      << here, things go bad...
0x00007f26b04fbf36:     mov    0x10(%rdi),%r12
0x00007f26b04fbf3a:     mov    0x18(%rdi),%r13
0x00007f26b04fbf3e:     mov    0x20(%rdi),%r14
0x00007f26b04fbf42:     mov    0x28(%rdi),%r15
0x00007f26b04fbf46:     mov    %esi,%eax
0x00007f26b04fbf48:     mov    %r8,%rsp
0x00007f26b04fbf4b:     mov    %r9,%rbp
0x00007f26b04fbf4e:     jmpq   *%rdx

(gdb) i
(top-gdb) c
Continuing.
(gdb) up
#1  0x000000000040067d in main () 
at ../../../src/gdb/testsuite/gdb.base/longjmp.c:96
96        if (setjmp (env) == 0)
(gdb) i
(top-gdb) p /x get_frame_id (selected_frame)
$3 = {stack_addr = 0xe706f6f457b7fe24, code_addr = 0x400664, special_addr = 
0x0, stack_addr_p = 0x1,
  code_addr_p = 0x1, special_addr_p = 0x0}

When the longjmp breakpoint was hit it looked like:
Breakpoint 3, handle_inferior_event (ecs=0x7fffcdfb48f0) 
at ../../src/gdb/infrun.c:2605
2605            ecs->stepping_through_longjmp = 1;
(top-gdb) p /x ecs->longjmp_caller_frame
$1 = {stack_addr = 0x7fff087e7b20, code_addr = 0x400664, special_addr = 0x0, 
stack_addr_p = 0x1, code_addr_p = 0x1,
  special_addr_p = 0x0}

Notice that stack_addr is now different of the original 0x7fff087e7b20,
although, the $sp is unwinds ok,
(top-gdb) c
Continuing.
(gdb) p $sp
$1 = (void *) 0x7fff087e7b00

x86 is even worse:

99            longjmp (env, 1); /* patt1 */
(gdb) n
0xf7da41c3 in ?? () from /lib32/libc.so.6
(gdb) bt
#0  0xf7da41c3 in ?? () from /lib32/libc.so.6
#1  0xffb327a8 in ?? ()
#2  0xf7da413c in siglongjmp () from /lib32/libc.so.6
Backtrace stopped: frame did not save the PC
(gdb) disassemble ($pc-10) ($pc+20)
Dump of assembler code from 0xf7da41b9 to 0xf7da41d7:
0xf7da41b9:     nop
0xf7da41ba:     nop
0xf7da41bb:     nop
0xf7da41bc:     nop
0xf7da41bd:     nop
0xf7da41be:     nop
0xf7da41bf:     nop
0xf7da41c0:     push   %ebp
0xf7da41c1:     mov    %esp,%ebp
0xf7da41c3:     push   %ebx         <<< fails here, just while
                                    <<< setting up a new frame...
0xf7da41c4:     call   0xf7d8f290 <_Unwind_Find_FDE@plt+120>
0xf7da41c9:     add    $0x11fe2b,%ebx
0xf7da41cf:     sub    $0x8,%esp
0xf7da41d2:     mov    0x340c(%ebx),%eax
End of assembler dump.
(gdb)                                                                      

Any ideas?

-- 
Pedro Alves