From: Horms <horms@verge.net.au>
To: Keir Fraser <Keir.Fraser@cl.cam.ac.uk>
Cc: xen-devel@lists.xensource.com
Subject: Re: [PATCH] gdbserver-xen: fix corefile access
Date: Fri, 3 Mar 2006 10:20:21 +0900 [thread overview]
Message-ID: <20060303012020.GA23154@verge.net.au> (raw)
In-Reply-To: <7afbce7d550a4b6dcfa8c6809496d027@cl.cam.ac.uk>
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
next prev parent reply other threads:[~2006-03-03 1:20 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-03-02 8:28 [PATCH] gdbserver-xen: fix corefile access Horms
2006-03-02 10:45 ` Keir Fraser
2006-03-02 12:19 ` Horms
2006-03-02 13:24 ` Keir Fraser
2006-03-03 1:20 ` Horms [this message]
2006-03-03 1:28 ` Horms
2006-03-03 8:11 ` Keir Fraser
2006-03-03 11:15 ` Horms
2006-03-03 13:02 ` Keir Fraser
2006-03-06 10:08 ` Horms
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060303012020.GA23154@verge.net.au \
--to=horms@verge.net.au \
--cc=Keir.Fraser@cl.cam.ac.uk \
--cc=xen-devel@lists.xensource.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.