From: Harvey Harrison <harvey.harrison@gmail.com>
To: "H. Peter Anvin" <hpa@zytor.com>
Cc: Ingo Molnar <mingo@elte.hu>, LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Roland McGrath <roland@redhat.com>
Subject: Re: [PATCH] x86: Use v8086_mode helper, trivial unification
Date: Thu, 17 Jan 2008 17:15:52 -0800 [thread overview]
Message-ID: <1200618952.5724.85.camel@brick> (raw)
In-Reply-To: <478FF9F3.9030604@zytor.com>
Roland actually put on CC this time.
On Thu, 2008-01-17 at 19:59 -0500, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> >
> > Sorry, missed that detail in ptrace.h, I notice now.
> >
> > Is there some better way this could be organized, would the following
> > be an improvement, as opposed to two long ifdef sections?
> >
> > Patch will follow if you think it's a good idea.
>
> It is actually quite a bit easier to read.
I'll send along a patch along soon, any thoughts on how to order it in
the file?
>
> >
> > static inline unsigned long stack_pointer(struct pt_regs *regs)
> > {
> > #ifdef CONFIG_X86_32
> > return (unsigned long)regs;
> > #else
> > return regs->sp;
> > #endif
> > }
>
> This one is kind of strange. In particular, the 32-bit definition isn't
> exactly what one would expect. It makes me concerned that it actually
> refers to two different kinds of stack pointers?
This tripped up the kprobes unification as well, see the stack_addr()
helper that was introduced there. Would be good to figure this out
and put a big fat comment on it.
kprobes.c
#ifdef CONFIG_X86_64
#define stack_addr(regs) ((unsigned long *)regs->sp)
#else
/*
* "®s->sp" looks wrong, but it's correct for x86_32. x86_32 CPUs
* don't save the ss and esp registers if the CPU is already in kernel
* mode when it traps. So for kprobes, regs->sp and regs->ss are not
* the [nonexistent] saved stack pointer and ss register, but rather
* the top 8 bytes of the pre-int3 stack. So ®s->sp happens to
* point to the top of the pre-int3 stack.
*/
#define stack_addr(regs) ((unsigned long *)®s->sp)
#endif
> > /* still need a define here, as one is long and one is unsigned long.
> > * but this is another target for unification I guess. */
> > #define regs_return_value(regs) ((regs)->ax)
>
> Indeed...
I think this comes out of Roland's patches unifying some names eip/rip,
eax/rax, etc.
CC'd in case he felt like more work ;-)
Harvey
next prev parent reply other threads:[~2008-01-18 1:16 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 23:04 [PATCH] x86: Use v8086_mode helper, trivial unification Harvey Harrison
2008-01-17 23:02 ` H. Peter Anvin
2008-01-17 23:26 ` Harvey Harrison
2008-01-18 0:59 ` H. Peter Anvin
2008-01-18 1:14 ` Harvey Harrison
2008-01-18 1:14 ` H. Peter Anvin
2008-01-18 1:23 ` Harvey Harrison
2008-01-18 1:15 ` Harvey Harrison [this message]
2008-01-18 1:37 ` Roland McGrath
2008-01-18 1:36 ` H. Peter Anvin
2008-01-18 2:02 ` Harvey Harrison
2008-01-18 2:21 ` Harvey Harrison
2008-01-18 3:35 ` H. Peter Anvin
2008-01-18 4:28 ` [PATCH] x86: Rename stack_pointer to kernel_trap_sp Harvey Harrison
2008-01-18 9:07 ` Ingo Molnar
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=1200618952.5724.85.camel@brick \
--to=harvey.harrison@gmail.com \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=roland@redhat.com \
--cc=tglx@linutronix.de \
/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.