This is the mail archive of the
mailing list for the GDB project.
Comments on U_REGS_OFFSET and fetch_register...
- To: gdb at sourceware dot cygnus dot com
- Subject: Comments on U_REGS_OFFSET and fetch_register...
- From: Kevin Buettner <kevinb at cygnus dot com>
- Date: Fri, 9 Jun 2000 12:22:35 -0700
In infptrace.c, U_REGS_OFFSET is (conditionally) defined as follows:
/* U_REGS_OFFSET is the offset of the registers within the u area. */
#if !defined (U_REGS_OFFSET)
#define U_REGS_OFFSET \
ptrace (PT_READ_U, inferior_pid, \
(PTRACE_ARG3_TYPE) (offsetof (struct user, u_ar0)), 0) \
And later on, in fetch_register(), we have the following code:
/* Overload thread id onto process id */
if ((tid = TIDGET (inferior_pid)) == 0)
tid = inferior_pid; /* no thread id, just use process id */
offset = U_REGS_OFFSET;
*(PTRACE_XFER_TYPE *) & buf[i] = ptrace (PT_READ_U, tid,
(PTRACE_ARG3_TYPE) regaddr, 0);
I have two problems with this code.
1) U_REGS_OFFSET is still using the composite thread id / process id.
It should only be using the actual pid extracted from
In my opinion, U_REGS_OFFSET should be changed (everywhere) to
take the pid as an argument.
2) The tid being extracted is later passed to ptrace(). While this
is fine for linux, where the tid is actually a pid which makes
sense to pass to ptrace(), I really doubt it makes sense for other
threads implementations where the thread id is something else
I'm not sure what to do about this problem. Perhaps its a moot
point since native ports where this could be a problem likely
define FETCH_INFERIOR_REGISTERS in order to do the right thing
when it comes to the thread id. Still it looks more than a little
strange to be passing the thread id to ptrace().