From: Hui Zhu <teawater@gmail.com>
To: Doug Evans <dje@google.com>
Cc: Michael Snyder <msnyder@vmware.com>,
"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>,
Daniel Jacobowitz <dan@codesourcery.com>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
Eli Zaretskii <eliz@gnu.org>
Subject: Re: [Fwd: Re: [RFA 3/5] Prec: x86 segment register support: target]
Date: Thu, 25 Mar 2010 02:14:00 -0000 [thread overview]
Message-ID: <daef60381003241914s1f4cd8ffre2d167a24f259abc@mail.gmail.com> (raw)
In-Reply-To: <e394668d1003241144p56be52d5i70ef700e7f60102f@mail.gmail.com>
On Thu, Mar 25, 2010 at 02:44, Doug Evans <dje@google.com> wrote:
>
> On Mon, Mar 22, 2010 at 7:59 PM, Hui Zhu <teawater@gmail.com> wrote:
> > On Tue, Mar 23, 2010 at 02:47, Doug Evans <dje@google.com> wrote:
> >> On Mon, Mar 22, 2010 at 11:26 AM, Michael Snyder <msnyder@vmware.com> wrote:
> >>> I'd just like to point out that while all this sounds great,
> >>> it shouldn't be a prerequisite to the original task of just
> >>> getting prec to record the segments and offsets correctly.
> >>>
> >>> Maybe we should split these two tasks, so that Teawater can
> >>> go ahead and accomplish his.
> >>
> >> To the extent that they can be split, IWBN alright.
> >>
> >> I wonder if the interface is sufficient though (setting aside where to
> >> put it and how it will look).
> >> Any particular o/s might not provide sufficient hooks of course.
> >> linux's modify_ldt, AIUI, let's one change more than just foo_base.
> >> NativeClient http://code.google.com/p/nativeclient/ uses it, for example.
> >>
> >
> > Thanks Doug.
> >
> > I suggest we support segment base step by step.
> > When the OS that support it will show the xxx_base to user, the
> > unsupport OS will show nothing.
> >
> > What do you think about it?
>
> Is supporting segment base sufficient?
> Or do you also need to support, e.g., segment limit and flags too?
> There may be more, but they're the two that come to mind.
> [That's what I was referring to regarding whether the interface was sufficient.]
Prec just need the base to get the insn memory operate address. Do
you think we need other message of segment?
If need, do we need divide all message like eflags?
Thanks,
Hui
next prev parent reply other threads:[~2010-03-25 2:14 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-03-22 18:26 Michael Snyder
2010-03-22 18:47 ` Doug Evans
2010-03-23 3:00 ` Hui Zhu
2010-03-24 18:44 ` Doug Evans
2010-03-25 2:14 ` Hui Zhu [this message]
2010-04-30 6:29 ` Hui Zhu
2010-04-30 9:36 ` Mark Kettenis
2010-04-30 11:07 ` Hui Zhu
2010-05-05 2:47 ` Hui Zhu
2010-05-10 2:14 ` Hui Zhu
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=daef60381003241914s1f4cd8ffre2d167a24f259abc@mail.gmail.com \
--to=teawater@gmail.com \
--cc=dan@codesourcery.com \
--cc=dje@google.com \
--cc=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=msnyder@vmware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox