[Bug gdb/19811] register value is not correct in catchpoint syscall execve after vfork

["palves at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=19811

Pedro Alves <palves at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |palves at redhat dot com

--- Comment #1 from Pedro Alves <palves at redhat dot com> ---
With 7.11.1 and gdb master, on x86_64, what I get is that gdb only stops on
exec syscall return, not entry:

~~~~~~
$ /usr/local/bin/gdb-7.11.1  -q   -ex 'set follow-fork-mode child' -ex 'catch
syscall execve' -ex r  --args gcc -xc - 
Reading symbols from gcc...Reading symbols from
/usr/lib/debug/usr/bin/x86_64-edhat-linux-gcc.debug...done.
done.
Catchpoint 1 (syscall 'execve' [59])
Starting program: /usr/bin/gcc -xc -
[New process 9809]
process 9809 is executing new program:
/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/cc1
[Switching to process 9809]

Thread 2.1 "cc1" hit Catchpoint 1 (returned from syscall execve),
0x00007ffff7ddcc80 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) 
~~~~~~

At this point most registers are indeed 0, but that's probably normal.
If I catch vfork first, si to follow the child, and then continue, then I can
catch the execve entry, and at that point the registers look correct:

~~~~~~
$ /usr/local/bin/gdb-7.11.1  -q  -ex 'set follow-fork-mode child' -ex "catch
fork" -ex "catch vfork"  -ex 'catch syscall execve' -ex r  --args gcc -xc -  
Reading symbols from gcc...Reading symbols from
/usr/lib/debug/usr/bin/x86_64-redhat-linux-gcc.debug...done.
done.
Catchpoint 1 (fork)
Catchpoint 2 (vfork)
Catchpoint 3 (syscall 'execve' [59])
Starting program: /usr/bin/gcc -xc -

Catchpoint 2 (vforked process 10018), vfork () at
../sysdeps/unix/sysv/linux/x86_64/vfork.S:52
52              pushq   %rdi
(gdb) si
[New process 10018]
58              testq   %rax, %rax
(gdb) c
Continuing.

Thread 2.1 "gcc" hit Catchpoint 3 (call to syscall execve), 0x00007ffff77e1897
in execve () at ../sysdeps/unix/syscall-template.S:84
84      T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) info registers 
rax            0xffffffffffffffda       -38
rbx            0x701460 7345248
rcx            0x7ffff77e1897   140737345624215
rdx            0x7008d0 7342288
rsi            0x7012e8 7344872
rdi            0x701460 7345248
rbp            0x1      0x1
rsp            0x7fffffffc6e8   0x7fffffffc6e8
r8             0x0      0
r9             0x0      0
r10            0x96     150
r11            0x206    518
r12            0x0      0
r13            0x0      0
r14            0x701460 7345248
r15            0x7012e8 7344872
rip            0x7ffff77e1897   0x7ffff77e1897 <execve+7>
eflags         0x206    [ PF IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb) c
Continuing.
process 10018 is executing new program:
/usr/libexec/gcc/x86_64-redhat-linux/5.3.1/cc1

Thread 2.1 "cc1" hit Catchpoint 3 (returned from syscall execve),
0x00007ffff7ddcc80 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) info registers 
rax            0x0      0
rbx            0x0      0
rcx            0x0      0
rdx            0x0      0
rsi            0x0      0
rdi            0x0      0
rbp            0x0      0x0
rsp            0x7fffffffd7b0   0x7fffffffd7b0
r8             0x0      0
r9             0x0      0
r10            0x0      0
r11            0x0      0
r12            0x0      0
r13            0x0      0
r14            0x0      0
r15            0x0      0
rip            0x7ffff7ddcc80   0x7ffff7ddcc80 <_start>
eflags         0x200    [ IF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0
(gdb) 
~~~~~~

So the problem might be two problems, actually:

#1 - Older gdb's got confused with execve entry/exit.

#2 - We can't catch execve entry for some reason.  Might be a kernel bug, not
sure.  I'm testing on Linux 4.6.4-201.fc23.x86_64, Fedora 23.

-- 
You are receiving this mail because:
You are on the CC list for the bug.