Gdb pending breakpoint does not resolve

Question

My system is Debian 64 bit

I have written a simple hello world program in c

2       #include <string.h>
3
4       int main() {
5               char str_a[20];
6
7               strcpy(str_a, "Hello, world!\n");
8               printf(str_a);
9       }

Compiled it with gcc -g -o char_array2 char_array2.c And fed into gdb via gdb -q ./char_array2

Now when i try to set up a breakpoint at strcpy like this

(gdb) break strcpy
Function "strcpy" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 2 (strcpy) pending.
(gdb)

and try to run it, the breakpoint is not resolved, "Hello world" is printed out and the program terminates.

What SHOULD have happenend after pressing run

Breakpoint 4, 0xb7f076f4 in strcpy () from /lib/tls/i686/cmov/libc.so.6

Now i have read this in a book that teaches assembly on a 32bit system and also the path shows /i686/, so i suspect that there is some sort of funcitonality missing due to me using a 64bit processor. How can i fix this?

There probably is no actual call to `strcpy`. Instead, the compiler just inlined the necessary assembly to initialize the array. — David Schwartz, Sep 22 '20 at 23:28
Even with optimization disabled, GCC still treats `strcpy` as a builtin function and copies that copy from a literal into just a `mov`-immediate, because the arg is a constant part of the same statement. https://godbolt.org/z/GvP8vn. Compile with `-fno-builtin` if you want GCC to be dumb. — Peter Cordes, Sep 22 '20 at 23:29
[What exactly is -fno-builtin doing here?](https://stackoverflow.com/q/54281780) is an exact duplicate of your question, with the same source and the same problem, including the same GDB error message, except they're still compiling for 32-bit mode. Maybe you got unlucky and the search terms you used didn't turn that up. — Peter Cordes, Sep 22 '20 at 23:32

score 1 · Answer 1 · answered Sep 22 '20 at 23:31

When I compile your code with your compile options on x686, I get this:

    leaq    -32(%rbp), %rax
    movabsq $8583909746840200520, %rdx
    movq    %rdx, (%rax)
    movl    $1684828783, 8(%rax)
    movw    $2593, 12(%rax)
    movb    $0, 14(%rax)

Notice, there is no call to strcpy. The compiler has inlined the logic. With -fno-builtin, I get this:

    leaq    -32(%rbp), %rax
    leaq    .LC0(%rip), %rsi
    movq    %rax, %rdi
    call    strcpy@PLT
    .loc 1 8 16

Gdb pending breakpoint does not resolve

1 Answers1