GDB skips shared library breakpoint

Question

Im using a debugger with a simple C program, im trying to set a breakpoint with a shared library, but GDB skips this breakpoint entirely.

Im trying to use GDB with a simple C program to learn about GDB. I set 3 breakpoints, 1 at line 7, one at the strcpy function, and one at line 8. I try to set a breakpoint in my program involving a shared library (specifically "break strcpy"), but every time I run the program and press "c", the program skips breakpoint 2 entirely

#include <stdio.h>
#include <string.h>

int main() {
    char str_a[20];

    strcpy(str_a, "Hello, world!\n");
    printf(str_a);
}

Whenever I run the program in the debugger, it stops normally at breakpoint 1, which is expected, but then whenever I press "c" to continue to breakpoint 2, it skips breakpoint 2 entirely and just shows the output breakpoint 3 is supposed to have. Is this something to do with GDB's handling of shared libraries?

EDIT: Here is the disassembly

    0x0000555555555145 <+0>:    push   rbp
    0x0000555555555146 <+1>:    mov    rbp,rsp
    0x0000555555555149 <+4>:    sub    rsp,0x20
    0x000055555555514d <+8>:    lea    rax,[rbp-0x20]
    0x0000555555555151 <+12>:   lea    rsi,[rip+0xeac]        # 0x555555556004
    0x0000555555555158 <+19>:   mov    rdi,rax
    0x000055555555515b <+22>:   call   0x555555555030 <strcpy@plt>
    0x0000555555555160 <+27>:   lea    rax,[rbp-0x20]
    0x0000555555555164 <+31>:   mov    rdi,rax
    0x0000555555555167 <+34>:   mov    eax,0x0
    0x000055555555516c <+39>:   call   0x555555555040 <printf@plt>
    0x0000555555555171 <+44>:   mov    eax,0x0
    0x0000555555555176 <+49>:   leave  
    0x0000555555555177 <+50>:   ret

Try with -fno-builtins. If that doesn't work, post the disassembly. — nemequ, Jul 10 '19 at 02:08
It works for me, and it looks like I get basically the same assembly. Did you try setting the breakpoint on the version compiled with `-fno-builtin`? — nemequ, Jul 10 '19 at 03:40

Employed Russian · Answer 1 · 2019-07-10T04:49:54.660

1

You didn't specify your platform. I suspect it's Linux with GLIBC.

The reason GDB behaves this way is that strcpy is not a normal function, but a GNU IFUNC.

Try setting breakpoint on __strcpy_sse2_unaligned and see this answer.

Update:

the debugger spits out this error whenever it reaches breakpoint 2, "../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S: No such file or directory.

That isn't an error.
The fact that it reaches that breakpoint confirms that this answer is correct.
You can simply treat __strcpy_sse2_unaligned as an alias to strcpy. Setting a breakpoint there is (on your system) equivalent to setting it on strcpy.

edited Jul 10 '19 at 04:49

answered Jul 10 '19 at 03:27

Employed Russian

199,314
34
295
362

The Os that im using is called "Parrot OS", which is based on debian, hope this helps. Also, the debugger spits out this error whenever it reaches breakpoint 2, "../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S: No such file or directory. " – Jul 10 '19 at 03:50
It's reaching the breakpoint, you just don't have debugging symbols for libc installed. Fedora's gdb will tell you the exact command you should use to install them, but IIRC on Debian it should be `apt-get install libc6-dbg` – nemequ Jul 10 '19 at 04:18
I installed this but it still spits out the same error message. – Jul 10 '19 at 04:28
The message "Pending breakpoint "strcpy" resolved" does not show up when running the program. This might be an important detail. – Jul 10 '19 at 04:41
@highboi I've updated the answer. You are now getting the breakpoint you wanted, and should also understand what was happening. – Employed Russian Jul 10 '19 at 04:50

GDB skips shared library breakpoint

1 Answers1