|
Size: 5263
Comment: fix link to PR
|
← Revision 41 as of 2013-05-13 18:18:03 ⇥
Size: 5032
Comment: use interwiki links for PRs
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 22: | Line 22: |
| ||mixed multi-arch ||X || || in-progress || [[http://sourceware.org/bugzilla/show_bug.cgi?id=14823|PR 14823]] || Pedro ||Although GDBserver supports biarch, when debugging multiple processes, they must all be of the same arch. || | ||mixed multi-arch ||X || || in-progress || Sourceware:PR14823 || Pedro ||Although GDBserver supports biarch, when debugging multiple processes, they must all be of the same arch. || |
| Line 28: | Line 28: |
| ||chain of pending signals|| ||X || || [[http://sourceware.org/bugzilla/show_bug.cgi?id=9381|PR 9381]]? || || || | ||chain of pending signals|| ||X || || Sourceware:PR9381 ? || || || |
| Line 31: | Line 31: |
| ||attach to stopped process||X || || fixed || [[http://sourceware.org/bugzilla/show_bug.cgi?id=9684|PR 9684]] || Pedro ||attach-stopped.exp || | ||attach to stopped process||X || || fixed || Sourceware:PR9684 || Pedro ||attach-stopped.exp || |
| Line 37: | Line 37: |
| ||info threads output different between native/remote.|| in-progress || [[http://sourceware.org/bugzilla/show_bug.cgi?id=14817|PR 14817]] || Pedro || gdbserver doesn't extract pthread ids out of thread_db. There's no way for gdbserver to affect target_pid_to_str's output. || | ||info threads output different between native/remote.|| in-progress || Sourceware:PR14817 || Pedro || gdbserver doesn't extract pthread ids out of thread_db. There's no way for gdbserver to affect target_pid_to_str's output. || |
| Line 40: | Line 40: |
| || PR12967 || || || || gdb.python/py-evsignal.exp and gdb.python/py-evthreads.exp use non-stop, if they don't, then we trip on [[http://sourceware.org/bugzilla/show_bug.cgi?id=12967|PR12967]]. || | || PR12967 || || || || gdb.python/py-evsignal.exp and gdb.python/py-evthreads.exp use non-stop, if they don't, then we trip on Sourceware:PR12967. || |
Local/remote debugging feature parity
GDBserver supports features native debugging does not support. Native debugging supports features GDBserver does not support.
The aim of this project is bridging the gap between both worlds.
Neither target backend is a superset of the other currently. A secondary goal of this project is making it possible to share a single target backend between native debugging and GDBserver (on GNU/Linux at first), by making the GDBserver backend support all of GDB's native backend's features (and more).
Getting the code / Helping
Discussions are held on the main GDB mailing lists. Patches should be posted to the gdb-patches mailing list. Work is being committed directly to the mainline (i.e., there's no special feature branch).
For testing, run the testsuite using the native-extended-gdbserver.exp board file under src/gdb/testsuite/boards/ and compare the results to the results of a native test run. The native-extended-gdbserver.exp board file tests GDB against a GDBserver running on the local host (the board file takes care of spawning GDBserver), and has GDB connect to GDBserver in extended-remote mode, which allows "run" "attach", etc., just like when debugging with the native target. Ideally, the results between both runs would be identical.
TODO/Feature comparison
Feature |
Native |
GDBserver |
Status |
PR |
Owner |
Notes |
follow fork/exec |
X |
|
|
|
|
|
inferior IO |
X |
|
|
|
|
|
tracepoints |
|
X |
|
|
|
|
fast tracepoints / IPA |
|
X |
|
|
|
|
mixed multi-arch |
X |
|
in-progress |
Pedro |
Although GDBserver supports biarch, when debugging multiple processes, they must all be of the same arch. |
|
set inferior env (set environment) |
X |
|
|
|
|
Exposed by solib-nodir.exp, testenv.exp |
set inferior cwd (cd/pwd) |
X |
|
|
|
|
Exposed by solib-nodir.exp |
catch syscall |
X |
|
|
|
|
|
attach auto-load exec |
X |
|
|
|
|
target_pid_to_exec_file |
TARGET_WAITKIND_NO_RESUMED / graceful leader-exits |
X |
|
|
|
|
leader-exit.exp, no-unwaited-for-left.exp, non-ldr-exc-*.exp |
chain of pending signals |
|
X |
|
PR9381 ? |
|
|
can access memory of running thread |
|
X |
|
|
|
can set breakpoints, inspect globals, etc. |
static libthread_db / no-libthread_db |
|
X |
|
|
|
|
attach to stopped process |
X |
|
fixed |
Pedro |
attach-stopped.exp |
|
attach to signalled process |
X |
|
fixed |
|
Pedro |
attach-into-signal.exp |
Other TODOs/Issues
Feature |
Status |
PR |
Owner |
Notes |
info threads output different between native/remote. |
in-progress |
Pedro |
gdbserver doesn't extract pthread ids out of thread_db. There's no way for gdbserver to affect target_pid_to_str's output. |
|
attach output is different native/remote |
done |
|
Pedro |
Revealed by several tests failing (extended-remote). |
We can't flip non-stop mode on after "target extended-remote". |
|
|
|
All non-stop tests fail with the current extended-remote board file due to this. Affected tests: gdb.python/py-evsignal.exp gdb.python/py-evthreads.exp |
PR12967 |
|
|
|
gdb.python/py-evsignal.exp and gdb.python/py-evthreads.exp use non-stop, if they don't, then we trip on PR12967. |
gdbserver: Unexpected missing PT_PHDR |
done |
|
Pedro |
with break-interp.exp, we see a lot of "gdbserver: Unexpected missing PT_PHDR" in the gdb.log. Maybe harmless? |
the annota2.exp and annota3.exp fail with the extended-remote board. |
|
|
|
|
gcore.exp system-core.exp float.exp fail on native, but pass with gdbserver. |
done |
|
Pedro |
AVX/xsave related. Patch posted here. |
signal other than SIGSTOP on CLONE events |
done |
|
Pedro |
gdbserver/linux-low.c:stopped_pids list doesn't hold the lwp's status. It is assumed that the status is a SIGSTOP. That's not always true, and, GDB/linux-nat.c:stopped_pids does store the lwp's status. |
"[Thread debugging using libthread_db enabled]" "Using host libthread_db library "/lib64/libthread_db.so.1"." |
|
|
|
Should we forward such messages back to gdb? |
Finding new threads in the inferior |
|
|
|
Native GNU/Linux debugging adds new threads to the thread list as the program creates them "The [New Thread foo] messages". Remote debugging can't do that, and it's arguable whether we shouldn't even stop native debugging from doing that, as it hinders inferior performance. However, a related issue is that with remote targets (and gdbserver), even after the program stops, the user still needs to do "info threads" to pull an updated thread list. This, should most likely be addressed, so that GDB pulls the list itself, perhaps just before presenting a stop to the user. |