GDB adapter steps into a function call instead of stepping over when the function is a part of the ld

[xusheng6]

While developing a new adapter on top of GDB RSP protocol I noticed that the GDB appears to be stepping into a function call rather than stepping over it as instructed. I noticed this does not happen on all code -- it works fine in code that is part of the binary being debugged, but it malfunctions when I step over on a function call right after attaching to a gdbserver. The code is part of the ld, though this may not be the actual reason.

Surprisingly, I tested with GDB and the same behavior is observed. That is quite surprising and puzzling since I remember I observe the same behavior on LLDB and thought it is a bug. Not sure if LLDB just inherits the bug, or this is an intended behavior? Below is an example output using the default gdb+gdbserver that comes with Ubuntu 22.04 that confirms the behavior:

gdb ~/debugger_build/debugger/test/binaries/Linux-x86_64/helloworld
GNU gdb (Ubuntu 12.1-0ubuntu1~22.04.2) 12.1
Reading symbols from /home/xusheng/debugger_build/debugger/test/binaries/Linux-x86_64/helloworld...
(No debugging symbols found in /home/xusheng/debugger_build/debugger/test/binaries/Linux-x86_64/helloworld)
(gdb) target remote 127.0.0.1:31337
Remote debugging using 127.0.0.1:31337
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/41/86944c50f8a32b47d74931e3f512b811813b64.debug...
Reading /usr/lib/debug/.build-id/c2/cfef17ec5fe1161b377b3403324a804253d71c.debug from remote target...
0x00007ffff7fe3290 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) ni
0x00007ffff7fe3293 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) x/10i $rip
=> 0x7ffff7fe3293 <_start+3>:	call   0x7ffff7fe4030 <_dl_start>
   0x7ffff7fe3298 <_dl_start_user>:	mov    %rax,%r12
   0x7ffff7fe329b <_dl_start_user+3>:	mov    0x19817(%rip),%eax        # 0x7ffff7ffcab8 <_dl_skip_args>
   0x7ffff7fe32a1 <_dl_start_user+9>:	pop    %rdx
   0x7ffff7fe32a2 <_dl_start_user+10>:	lea    (%rsp,%rax,8),%rsp
   0x7ffff7fe32a6 <_dl_start_user+14>:	sub    %eax,%edx
   0x7ffff7fe32a8 <_dl_start_user+16>:	push   %rdx
   0x7ffff7fe32a9 <_dl_start_user+17>:	mov    %rdx,%rsi
   0x7ffff7fe32ac <_dl_start_user+20>:	mov    %rsp,%r13
   0x7ffff7fe32af <_dl_start_user+23>:	and    $0xfffffffffffffff0,%rsp
(gdb) ni
Reading /lib/x86_64-linux-gnu/libc.so.6 from remote target...
[Inferior 1 (process 46934) exited with code 012]

(In this listing the target executes freely and then exits, but in other cases I have seen it step into the function instead)

Another thing I remembered is there was a user that I chatted with said our debugger works fine when it connects to a gdbserver. I was confused since in my test, the debugger will step into instead of step over. However, it might be the case that he cares more about the code in the binary so he has never stepped over on a function call that is part of ld. Stepping over in on the code that is part of the binary works as expected, so he thinks the debugger works properly. Me, on the other hand, was just testing the capacity of the debugger, and I only stepped over a few times in the ld code and noticed the behavior.

Debugger is complicated!