This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[riscv] gdb hangs when stepping off a breakpoint and setting more hardware breakpoints than the target supports


I'm running into a problem I can't figure out while working on RISC-V
support. I realize that RISC-V support is not in gdb, but I'm hoping
that somebody can read this problem report and give me a hint as to
what I should be looking at.

The problem occurs when running off a software breakpoint, while
attempting to set more hardware breakpoints than the target support.
(My target supports 2 hardware breakpoints, so in my testcase I
attempt to set 3 of them.) The immediate behavior is correct: gdb
determines it cannot set the last hardware breakpoint, and aborts the
run request. The next time I resume (c), however, gdb never asks
OpenOCD to do anything, and just ends up in a loop that only ^C
interrupts. This happens regardless of whether I delete the hardware
breakpoints or not.

When gdb hangs, the cause appears to be that step_over_info.aspace is
set, which is checked at the start of start_step_over() (by calling
step_over_info_valid_p()). If I debug the gdb process and clear that
value just before it's checked, then everything works as expected.

Usually step_over_info.aspace is set here:
#0  set_step_over_info (thread=1, nonsteppable_watchpoint_p=0,
    address=2147484830, aspace=0xc98cf0) at infrun.c:1342
#1  keep_going_pass_signal (ecs=0x7fffffffdf10) at infrun.c:7804
#2  0x000000000058de42 in start_step_over () at infrun.c:2148
#3  0x000000000058e242 in proceed (addr=addr@entry=18446744073709551615,
    siggnal=siggnal@entry=GDB_SIGNAL_DEFAULT) at infrun.c:3140
#4  0x0000000000583145 in continue_1 (all_threads=0) at infcmd.c:764

And later step_over_info.aspace is cleared here:
#0  clear_step_over_info () at infrun.c:1356
#1  0x0000000000590648 in finish_step_over (ecs=0x7fffffffe350)
    at infrun.c:5575
#2  handle_signal_stop (ecs=0x7fffffffe350) at infrun.c:5692
#3  0x0000000000592138 in handle_inferior_event_1 (ecs=0x7fffffffe350)
    at infrun.c:5395
#4  handle_inferior_event (ecs=ecs@entry=0x7fffffffe350) at infrun.c:5430
#5  0x000000000059335f in fetch_inferior_event (client_data=<optimized out>)
    at infrun.c:3935

However, when the user set more hardware breakpoints than are present
on the target, this second bit of code is never executed.
step_over_info.aspace is set as usual, but never cleared, because the
entire resume operation is aborted here:
#0  start_step_over () at infrun.c:2151
#1  0x000000000058e242 in proceed (addr=addr@entry=18446744073709551615,
    siggnal=siggnal@entry=GDB_SIGNAL_DEFAULT) at infrun.c:3140
#2  0x0000000000583145 in continue_1 (all_threads=0) at infcmd.c:764
#3  0x00000000005832e8 in continue_command (args=<optimized out>, from_tty=0)
    at infcmd.c:860

I was unable to reproduce this problem using x86 native debugging, so
there must be something that the riscv-tdep is not doing that can
solve this problem, but I am stumped as to what that might be.

Does anybody have any thoughts on what my next step should be?

Thank you,
Tim

For reference, here is a session displaying the problem:
tnewsome@compy-vm:~/SiFive/riscv-tools/riscv-tests/debug$
riscv64-unknown-elf-gdb HiFive1_debug-32
GNU gdb (GDB) 8.0.50.20170626-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu
--target=riscv64-unknown-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from HiFive1_debug-32...done.
(gdb) target extended-remote localhost:3333
Remote debugging using localhost:3333
0x800009b2 in _exit (status=-932948524)
    at /home/tnewsome/SiFive/riscv-tools/riscv-tests/debug/programs/init.c:14
14    while (i)
(gdb) load
Loading section .text, size 0x9c6 lma 0x80000000
Loading section .rodata, size 0x2b lma 0x800009c8
Loading section .sdata, size 0x4 lma 0x800009f4
Start address 0x80000000, load size 2549
Transfer rate: 191 KB/sec, 849 bytes/write.
(gdb) b main
Breakpoint 1 at 0x8000049e: file
/home/tnewsome/SiFive/riscv-tools/riscv-tests/debug/programs/debug.c,
line 52.
(gdb) c
Continuing.

Breakpoint 1, main ()
    at /home/tnewsome/SiFive/riscv-tools/riscv-tests/debug/programs/debug.c:52
52    __malloc_freelist = 0;
(gdb) hbreak rot13
Hardware assisted breakpoint 2 at 0x80000394: file
/home/tnewsome/SiFive/riscv-tools/riscv-tests/debug/programs/debug.c,
line 28.
(gdb) hbreak *4
Hardware assisted breakpoint 3 at 0x4
(gdb) hbreak *8
Hardware assisted breakpoint 4 at 0x8
(gdb) c
Continuing.
Warning:
Cannot insert hardware breakpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

Command aborted.
(gdb) delete 3-4
(gdb) c
Continuing.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]