GDB and gdbserver cannot step on Linux targets

[kolerov]

A sample program:

#include <stdio.h>

int main()
{
        printf("Hello, World!\n");
        return 0;
}

Try to perform step on ARC HS3x/4x Linux host using native GDB:

# gdb -q main-hs4x-glibc
Reading symbols from main-hs4x-glibc...
(gdb) b main
warning: could not convert 'main' from the host encoding (ANSI_X3.4-1968) to UTF-32.
This normally should not happen, please file a bug report.
Breakpoint 1 at 0x540: file main.c, line 5.
(gdb) run
Starting program: /root/main-hs4x-glibc
Breakpoint 1, main () at main.c:5
warning: Source file is more recent than executable.
5               printf("Hello, World!\n");
(gdb) step
Warning:
Cannot insert breakpoint 0.
Cannot access memory at address 0x0

0x200629b8 in ?? ()

Try to perform stepi on ARC HS3x/4x Linux host using native GDB:

# gdb -q main-hs4x-glibc
Reading symbols from main-hs4x-glibc...
(gdb) b main
warning: could not convert 'main' from the host encoding (ANSI_X3.4-1968) to UTF-32.
This normally should not happen, please file a bug report.
Breakpoint 1 at 0x540: file main.c, line 5.
(gdb) run
Starting program: /root/main-hs4x-glibc
Breakpoint 1, main () at main.c:5
warning: Source file is more recent than executable.
5               printf("Hello, World!\n");
(gdb) stepi
0x40000548      5               printf("Hello, World!\n");
(gdb) stepi
0x4000054a      5               printf("Hello, World!\n");

The same issue exists when debugging using gdbserver on a target system. The issue may be reproduced at least for arc-2023.09 release and later.

[kolerov]

The issue may be reproduced both on QEMU and HSDK.

[shahab-vahedi]

I cannot reproduce this on a linux image that I built in march for ebpf testing. gdb is still version 14.2.

[kolerov]

I face the issue when stepping (using just step) over simple assignments, local function calls, etc., but not when stepping over glibc functions. stepi, next and nexti work fine.

[shahab-vahedi]

I can confirm that I do see incorrect behaviour with step but not as bad as what was described (simple assignments, functions calls, etc.). Unless more solid examples are provided, I'm afraid not much can be done.

Anyhow, this is the incorrect behaviour I observe:

(gdb) c
Continuing.

Breakpoint 1, main () at test.c:26
26          fprintf(stdout, "solved.\n");
(gdb) n
28          return 0;

vs.

Breakpoint 1, main () at test.c:26
26          fprintf(stdout, "solved.\n");
(gdb) s
[Inferior 1 (process 138) exited normally]
(gdb)

Here, when about to execute the fprintf(), using n leads to the next line, which is return 0. However, issuing s under the same circumstances, does not stop the process anymore. I think this can be generalised to "stepping into functions without debug symbols makes ARC gdb misbehave".

[shahab-vahedi]

This is how a native x86_64 gdb behaves:

(gdb) n
14    fprintf(stdout, "solved.\n");
(gdb) s
__GI__IO_fwrite (buf=..., size=1, count=8, fp=... <_IO_2_1_stdout_>)
    at ./libio/iofwrite.c:32
warning: 32 ./libio/iofwrite.c: No such file or directory
(gdb) fin
Run till exit from #0  __GI__IO_fwrite (buf=..., size=1, count=8,
    fp=... <_IO_2_1_stdout_>) at ./libio/iofwrite.c:32
solved.
main () at file.c:16
16    return 0;
Value returned is $1 = 8
(gdb) i r rax
rax            0x8                 8
(gdb)

It steps into the unknown (__GI__IO_fwrite (buf=..., size=1, count=8, fp=... <_IO_2_1_stdout_>) at ./libio/iofwrite.c:32 without any source information) and it's possible to finish it off.