Re: [Xen-devel] [PATCH] gdbserver-xen: fix corefile access

[Horms <horms@xxxxxxxxxxxx>]

On Thu, Mar 02, 2006 at 01:24:41PM +0000, Keir Fraser wrote:
> 
> On 2 Mar 2006, at 12:19, Horms wrote:
> 
> >>The correct fix is to update the xc_ptrace_core() interface to match
> >>the xc_ptrace() interface. Kip Macy made the latter SMP aware, but
> >>didn't fix up the former.
> >>
> >>It should be easy to do -- note how xc_ptrace() takes a domid on
> >>PTRACE_ATTACH, and vcpuid at all other times. xc_ptrace_core() should
> >>take a fd on PTRACE_ATTACH, and vcpuid at all other times. Since we
> >>don't dump SMP core files right now, vcpuid should either be ignored
> >>for the time being, or fail the call if vcpuid!=0.
> >
> >I didn't notice that, but I should have.
> >
> >Are you suggesting that xc_ptrace_core() should record the fd passed
> >to it on PTRACE_ATTACH and use that later, presumably in current_domid?
> >If so, yes that does look very easy. If not, can you explain a little
> >further? In any case, I'll look into it tomorrow.
> 
> Yeah, you should record it the same way that xc_ptrace() records the 
> domid. Really the two calls (xc_ptrace and xc_ptrace_core) should 
> probably be merged -- we could pass an extra flag to PTRACE_ATTACH to 
> indicate whether we are attaching to a coredump or to a live domain. 
> Then we could get rid of xc_ptrace_core altogether.

That sounds reasonable to me. Though internally the do different things,
so would the idea be to something like:

  rename xc_ptrace xc_ptrace_thread
  make xc_ptrace a wapper for xc_ptrace_thread and xc_ptrace_core

Also, I haven't poked into this, but it seems that
xc_waitdomain_core/xc_waitdomain could have the same treatment, and thus
both myptrace and myxcwait could be replaced with direct calls to
xc_ptrace and xc_waitdomain respectively.

-- 
Horms

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel