-
Notifications
You must be signed in to change notification settings - Fork 2
Home
Welcome to Pedro Alves's in-process GDB work home page.
WARNING: I STOPPED UPDATING THIS LONG AGO.
The "upstream/master" branch is a pristine mirror from upstream; check the other branches.
Most of these branches are rebase branches, meaning I'm rewriting history all the time, getting patches cleaned up for pushing upstream (using stgit). Use "git pull --rebase" if you decide to work on top.
This branch contains support for per-UI readline and TUI. This means command line editing on secondary consoles too, and even a TUI (curses) on each UI. E.g., start gdb like:
gdb -q -ex "new-ui tui /dev/pts/3"
and then do "C-x a" on both the primary and secondary UIs, you'll get one TUI instance per UI.
This branch is an attempt to salvage features in palves/console-old-mt that didn't make it to upstream master. It's built on top of the "struct ui"-based rewrite that landed upstream.
This is the original prototype for the whole UI work that eventually became:
[PATCH v3 00/34] Towards great frontend GDB consoles https://sourceware.org/ml/gdb-patches/2016-05/msg00098.html
It's ugly and not cleanly split into nice independent patches, but, it went all the way to make each console (later renamed UI in mainline) have its own TUI instance. Along the way, I had to make each console spawn its own thread. That in turn revealed problematic because all ptrace accesses must come from the same thread... Instead of introducing some kind of ptrace-request cross-thread marshalling inside gdb, I think the solution for that is to always spawn gdbserver, even for native debugging.
Same as the previous branch, except with the multi-threading bits disabled. Avoids the ptrace problem, but breaks if multiple consoles "query" at the same time.
x86 / amd64 software single-step implementation. Useful for testing changes that would affect software single-step targets, like ARM GNU/Linux or MIPS GNU/Linux, right on x86-64.
This forces single-step for all resumes, even "continue". Running the testsuite with this serves as a cheap strain test for software single-step, and displaced-stepping implementations (like x86's above).