aboutsummaryrefslogtreecommitdiff
path: root/gdb/common/ptid.h
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2014-02-19 18:25:40 +0000
committerPedro Alves <palves@redhat.com>2014-02-19 18:25:40 +0000
commitba3481708d3f18e77ab6c000385b131c76d2733e (patch)
tree42ad837859a867f2ad7d9a1bf90c64a2f5d4e016 /gdb/common/ptid.h
parentac01945bf17f3699de5493da23f14ea92549617a (diff)
downloadfsf-binutils-gdb-ba3481708d3f18e77ab6c000385b131c76d2733e.zip
fsf-binutils-gdb-ba3481708d3f18e77ab6c000385b131c76d2733e.tar.gz
fsf-binutils-gdb-ba3481708d3f18e77ab6c000385b131c76d2733e.tar.bz2
remote.c: Use the ptid.lwp field to store remote thread ids rather than ptid.tid.
From GDB's perspective, independently of how the target really implements threads, gdb/remote sees all threads as if kernel/system threads. A rationale along theses lines led to gdbserver storing thread ids in ptid.lwp in all ports. Because remote.c is currently using ptid.tid, we can't make gdbserver and gdb share bits of remote-specific code that manipulates ptids (e.g., write_ptid/read_ptid). This patch thus makes remote.c use ptid.lwp instead of ptid.tid. I believe that on the GDB side too, it's best that we standardize on process_stratum targets using the ptid.lwp field to store thread ids anyway. The idea being leave the ptid.tid field free for any thread_stratum target that might want to sit on top. Tested on x86_64 Fedora 17, w/ local gdbserver. gdb/ 2014-02-19 Pedro Alves <palves@redhat.com> * remote.c (remote_thread_alive, write_ptid, read_ptid) (read_ptid, remote_newthread_step, remote_threads_extra_info) (remote_get_ada_task_ptid, append_resumption, remote_stop_ns) (threadalive_test, remote_pid_to_str): Use the ptid.lwp field to store remote thread ids rather than ptid.tid. (_initialize_remote): Adjust.
Diffstat (limited to 'gdb/common/ptid.h')
0 files changed, 0 insertions, 0 deletions