Differences between revisions 51 and 52
Revision 51 as of 2013-10-09 11:40:22
Size: 5338
Editor: PedroAlves
Comment: add url pointing to the initial TARGET_WAITKIND_NO_RESUMED patch.
Revision 52 as of 2013-10-25 14:21:41
Size: 5451
Editor: PedroAlves
Comment:
Deletions are marked like this. Additions are marked like this.
Line 29: Line 29:
||use shell to start program ||X || || || || || wildcard expansion, variable replacement and I/O redirection ||

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.

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

Neither target backend is a superset of the other currently, so we can't just drop one of them. The headed direction is making the GDBserver backend support all of GDB's native backend's features (and more), and then drop GDB's.

See also the Common project.

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

Research

PR13584

Luis

inferior IO

X

tracepoints

X

fast tracepoints / IPA

X

mixed multi-arch

7.6

7.7

fixed

PR14823

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

use shell to start program

X

wildcard expansion, variable replacement and I/O redirection

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. See here.

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

7.5

fixed

PR9684

Pedro

attach-stopped.exp

attach to signalled process

X

7.5

fixed

Pedro

attach-into-signal.exp

3. Other TODOs/Issues

Feature

Status

PR

Owner

Notes

info threads output different between native/remote.

in-progress

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.

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.


OngoingWork

None: LocalRemoteFeatureParity (last edited 2014-12-05 12:15:05 by PedroAlves)

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