#14891 closed bug (invalid)
KDL: Calling gdb with no parameters causes KDL and system to hang
| Reported by: | SuperPrower | Owned by: | nobody |
|---|---|---|---|
| Priority: | normal | Milestone: | Unscheduled |
| Component: | - General | Version: | R1/Development |
| Keywords: | KDL, gdb | Cc: | |
| Blocked By: | Blocking: | ||
| Platform: | x86 |
Description
Opening KDL and typing gdb causes KDL and the entire system to hang with no way out, no timeout, only reboot. Probably this is unintended, maybe some kind of default settings for gdb that cause it to hang? I tried this on the same machine with x86_gcc2 hybrid system, both Beta and recently self-built.
Change History (4)
comment:1 by , 5 years ago
| Resolution: | → invalid |
|---|---|
| Status: | new → closed |
comment:2 by , 5 years ago
The kernel debugger can't run userland programs like GDB, only built-in commands written specifically for it.
That's understandable (and kinda obvious, to be honest)
The "gdb" command there does not run GDB itself, but rather a GDB stub so that you can then connect the serial port to a GDB session elsewhere.
Well, at least inner documentation could say run GDB server instead of connect to remote gdb, that would be really helpful
I think Ctrl+C may be a valid command sequence via GDB protocol, so not much we can do here.
So complete freeze is expected? (No possible variant of Modifier Key + C doesn't seem to work). Does GDB stub start in paused state, and the only way to resume is to connect to the stub and type continue?
comment:3 by , 5 years ago
Well, at least inner documentation could say run GDB server instead of connect to remote gdb, that would be really helpful
Technically it's correct as-is I think? (and "help gdb" in KDL will explain what the command does in more detail.)
Does GDB stub start in paused state, and the only way to resume is to connect to the stub and type continue?
I believe once you start the GDB stub, that it takes over and you can't go back to KDL prompt without exiting KDL, yes.
The kernel debugger can't run userland programs like GDB, only built-in commands written specifically for it. The "gdb" command there does not run GDB itself, but rather a GDB stub so that you can then connect the serial port to a GDB session elsewhere.
I think Ctrl+C may be a valid command sequence via GDB protocol, so not much we can do here.