Differences between revisions 38 and 39
Revision 38 as of 2012-11-09 14:42:13
Size: 5156
Editor: PedroAlves
Comment:
Revision 39 as of 2012-11-09 14:49:39
Size: 5256
Editor: PedroAlves
Comment: Add PR column.
Deletions are marked like this. Additions are marked like this.
Line 17: Line 17:
||'''Feature'''||'''Native'''||'''GDBserver'''||'''Status'''||'''Owner'''||'''Notes'''|| ||'''Feature'''||'''Native'''||'''GDBserver'''||'''Status'''||'''PR'''||'''Owner'''||'''Notes'''||
Line 19: Line 19:
||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. [[sourceware.org/bugzilla/show_bug.cgi?id=14823|PR 14823]].||
||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 || || ||[[http://sourceware.org/bugzilla/show_bug.cgi?id=9381|PR 9381]]?||
||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, but see [[http://sourceware.org/bugzilla/show_bug.cgi?id=9684|PR 9684]] ||
||attach to signalled process||X || || fixed || Pedro ||attach-into-signal.exp||
||inferior IO ||X || || || || || ||
||tracepoints || ||X || || || || ||
||fast tracepoints / IPA || ||X || || || || ||
||mixed multi-arch ||X || || in-progress || [[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. ||
||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 || || [[http://sourceware.org/bugzilla/show_bug.cgi?id=9381|PR 9381]]? || || ||
||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 || [[http://sourceware.org/bugzilla/show_bug.cgi?id=9684|PR 9684]] || Pedro ||attach-stopped.exp ||
||attach to signalled process||X || || fixed || || Pedro ||attach-into-signal.exp||
Line 36: Line 36:
||'''Feature'''||'''Status'''||'''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. See [[http://sourceware.org/bugzilla/show_bug.cgi?id=14817|PR 14817]]||
|| 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 http://sourceware.org/bugzilla/show_bug.cgi?id=12967. ||
|| 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 at http://sourceware.org/ml/gdb-patches/2012-01/msg00916.html ||
|| 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. ||
||'''Feature'''||'''Status'''||'''PR'''||'''Owner'''||'''Notes'''||
||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. ||
|| 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 [[http://sourceware.org/bugzilla/show_bug.cgi?id=12967|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 [[http://sourceware.org/ml/gdb-patches/2012-01/msg00916.html|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. ||

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).

1. 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.

2. 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

PR 14823

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

PR 9381?

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

PR 9684

Pedro

attach-stopped.exp

attach to signalled process

X

fixed

Pedro

attach-into-signal.exp

3. Other TODOs/Issues

Feature

Status

PR

Owner

Notes

info threads output different between native/remote.

in-progress

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.

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.

None: LocalRemoteFeatureParity (last edited 2014-07-30 19:21:17 by DougEvans)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.