This is the mail archive of the gdb@sourceware.cygnus.com 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) \
    - KERNEL_U_ADDR
#endif

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

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

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

Kevin


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