2

According to this thread, the 30th value (starting from 1) of /proc//stat should show the 'eip' value of the process .

Get instruction pointer of running application on Unix

But when I printed the 30th value of bash process, it kept returning the same address:

root@graphics:/proc# ps | grep bash
 3032 pts/21   00:00:00 bash
root@graphics:/proc# cd 3032
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a
root@graphics:/proc/3032# cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f53790ef84a

The same happened even for chrome. I thought the 'eip' value keeps changing dynamically as it executes. Why does it always returns the same address?

OK, after reading MingJie's answer, I made up my mind to see whether the value actually changes if I check it super-frequently. The target process was chrome, whose pid was 1834. Here is my bash script to check the value on behalf of me:

#!/bin/bash

EIP=
while true; do
    NEW_EIP=`cat /proc/1834/stat | awk '{print $30}' | xargs printf "0x%x"`
    if [[ "$NEW_EIP" != "$EIP" ]]; then
        echo "eip changed! (eip: " $NEW_EIP ")"
    fi

    EIP=$NEW_EIP
    echo $EIP >> $0.dump
done

The script was designed to print eip changed! message if the captured 30th value differs from the previously captured value. As I ran this script, it turned out that it is actually changing!

root@graphics:/home/gwangmu/Documents# ./eiptest 
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94e868ce0d )
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94e868ce0d )
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94e868cbfa )
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94e868ce0d )
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94e868d23d )
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94e868d23d )
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94e868ce0d )
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94ee983c7a )
eip changed! (eip:  0x7f94e711e8dd )
eip changed! (eip:  0x7f94ee7a1190 )
eip changed! (eip:  0x7f94e711e8dd )

I hope it'll be a little bit of help to someone else. Thanks MingJie!

Community
  • 1
  • 1
Gwangmu Lee
  • 437
  • 3
  • 12
  • That answer says it's the 29th field. OTOH what architecture are you on? Does it have a retrievable eip? – RedX Oct 09 '15 at 09:56
  • I tested it on a x86-64 machine. Since that answer starts its numbering from 0, I think it's OK to use *$30* for *awk*. – Gwangmu Lee Oct 09 '15 at 10:00

1 Answers1

1

When bash runs a program, it waits until the child process exit, so the eip is pointing to the exit address of waitpid call

/proc/9919$ cat stat | awk '{print $30}' | xargs printf "0x%x" && echo
0x7f037e3a831c

You can check it by using gdb

% gdb
(gdb) attach 9919
Attaching to process 9919
Reading symbols from /bin/bash...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libncurses.so.5...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so.5...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libdl.so.2...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libc.so.6...(no debugging symbols found)...done.
Reading symbols from /lib64/ld-linux-x86-64.so.2...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libnss_compat.so.2...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libnsl.so.1...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libnss_nis.so.2...(no debugging symbols found)...done.
Reading symbols from /lib/x86_64-linux-gnu/libnss_files.so.2...(no debugging symbols found)...done.
0x00007f037e3ca5e0 in read () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) disassemble 0x7f037e3a831c
Dump of assembler code for function waitpid:
   0x00007f037e3a8300 <+0>: mov    0x2f14cd(%rip),%r9d        # 0x7f037e6997d4
   0x00007f037e3a8307 <+7>: test   %r9d,%r9d
   0x00007f037e3a830a <+10>:    jne    0x7f037e3a8336 <waitpid+54>
   0x00007f037e3a830c <+12>:    xor    %r10d,%r10d
   0x00007f037e3a830f <+15>:    movslq %edx,%rdx
   0x00007f037e3a8312 <+18>:    movslq %edi,%rdi
   0x00007f037e3a8315 <+21>:    mov    $0x3d,%eax
   0x00007f037e3a831a <+26>:    syscall 
   0x00007f037e3a831c <+28>:    cmp    $0xfffffffffffff000,%rax
   0x00007f037e3a8322 <+34>:    ja     0x7f037e3a8325 <waitpid+37>
   0x00007f037e3a8324 <+36>:    retq   
   0x00007f037e3a8325 <+37>:    mov    0x2ebb3c(%rip),%rdx        # 0x7f037e693e68
   0x00007f037e3a832c <+44>:    neg    %eax
   0x00007f037e3a832e <+46>:    mov    %eax,%fs:(%rdx)
   0x00007f037e3a8331 <+49>:    or     $0xffffffffffffffff,%rax
   0x00007f037e3a8335 <+53>:    retq   
   0x00007f037e3a8336 <+54>:    push   %rbx
   0x00007f037e3a8337 <+55>:    sub    $0x10,%rsp
   0x00007f037e3a833b <+59>:    mov    %edx,0xc(%rsp)
   0x00007f037e3a833f <+63>:    mov    %rsi,(%rsp)
   0x00007f037e3a8343 <+67>:    mov    %edi,0x8(%rsp)
   0x00007f037e3a8347 <+71>:    callq  0x7f037e3e3620
   0x00007f037e3a834c <+76>:    mov    $0x3d,%ecx
   0x00007f037e3a8351 <+81>:    mov    %eax,%r8d
   0x00007f037e3a8354 <+84>:    xor    %r10d,%r10d
   0x00007f037e3a8357 <+87>:    movslq 0xc(%rsp),%rdx
   0x00007f037e3a835c <+92>:    mov    (%rsp),%rsi
   0x00007f037e3a8360 <+96>:    mov    %ecx,%eax
   0x00007f037e3a8362 <+98>:    movslq 0x8(%rsp),%rdi
   0x00007f037e3a8367 <+103>:   syscall 
   0x00007f037e3a8369 <+105>:   cmp    $0xfffffffffffff000,%rax
   0x00007f037e3a836f <+111>:   mov    %rax,%rbx
   0x00007f037e3a8372 <+114>:   ja     0x7f037e3a8384 <waitpid+132>
   0x00007f037e3a8374 <+116>:   mov    %r8d,%edi
   0x00007f037e3a8377 <+119>:   callq  0x7f037e3e3680
   0x00007f037e3a837c <+124>:   add    $0x10,%rsp
   0x00007f037e3a8380 <+128>:   mov    %ebx,%eax
   0x00007f037e3a8382 <+130>:   pop    %rbx
   0x00007f037e3a8383 <+131>:   retq   
   0x00007f037e3a8384 <+132>:   mov    0x2ebadd(%rip),%rax        # 0x7f037e693e68
   0x00007f037e3a838b <+139>:   neg    %ebx
   0x00007f037e3a838d <+141>:   mov    %ebx,%fs:(%rax)
   0x00007f037e3a8390 <+144>:   or     $0xffffffffffffffff,%rbx
   0x00007f037e3a8394 <+148>:   jmp    0x7f037e3a8374 <waitpid+116>
End of assembler dump.

0x7f037e3a831c is after a syscall in function waitpid

Zang MingJie
  • 5,164
  • 1
  • 14
  • 27
  • Thanks for the answer, but it seems it happens for any other processes, such as *chrome*. I forgot to mention this :( – Gwangmu Lee Oct 09 '15 at 10:23
  • To save cpu usage, usually all process should be blocking somewhere, otherwise it will consume 100% cpu. so its `eip` is pointing to the next instruction of the blocking syscall – Zang MingJie Oct 09 '15 at 10:28