[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



On Fri, Mar 03, 2006 at 10:28:05AM +0900, Horms wrote:
> On Fri, Mar 03, 2006 at 10:20:21AM +0900, Horms wrote:
> > 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
> 
> Sorry, scratch that. I think they can just be merged into one
> function, I'll try and get a patch together.
> 
> Do you think it would be better to pass the isfile flag in the form
> of PTRACE_ATTACH|XC_PTRACE_FILE as the third argument to xc_ptrace,
> or parhaps use the last argument to xc_ptrace, edata (or perhaps the
> second last one, eaddr), which are unused for ATTACH.

I have made a first pass at this, passing isfile as the data argument
to xc_ptrace() ATTACH. Its a little rough, but I wanted to get it out
for feedback before I head off for the day.

There are 4 patches attached, which need to be applied in order.
Please let me know if posting patches in this way is a problem.
And of course, please let me know of any and all objections
so that I can refactor (or explain) accordingly.

-- 
Horms


Attachment: 31-libxc_cosmecic-brackets.patch
Description: Text document

Attachment: 32-libxc_bogus-if.patch
Description: Text document

Attachment: 33-libxc_duplicate-xc_ptrace-code.patch
Description: Text document

Attachment: 34-libxc-gdbdebug_consolidate_xc_ptrace.patch
Description: Text document

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

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.