This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Comments on U_REGS_OFFSET and fetch_register...

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]