lkml.org 
[lkml]   [2008]   [Jan]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [PATCH] x86: Use v8086_mode helper, trivial unification
From
Date
On Thu, 2008-01-17 at 18:02 -0500, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> > Use v8086_mode inline in fault_32.c, no functional change
> > also ifdef the section for 32-bit only and add to fault_64.c
>
> The #ifdef is unnecessary, since v8086_mode() is now a constant zero on
> x86-64. gcc will remove the if clause.
>

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.

static inline int user_mode(struct pt_regs *regs)
{
#ifdef CONFIG_X86_32
return (regs->cs & SEGMENT_RPL_MASK) == USER_RPL;
#else
return !!(regs->cs & 3);
#endif
}

static inline int user_mode_vm(struct pt_regs *regs)
{
#ifdef CONFIG_X86_32
return ((regs->cs & SEGMENT_RPL_MASK) |
(regs->flags & VM_MASK)) >= USER_RPL;
#else
return user_mode(regs);
#endif
}

static inline int v8086_mode(struct pt_regs *regs)
{
#ifdef CONFIG_X86_32
return (regs->flags & VM_MASK);
#else
return 0;
#endif
}

/* OK, maybe this should just be deleted, and use
regs->ip directly in code*/
static inline unsigned long instruction_pointer(struct pt_regs *regs)
{
return regs->ip;
}

/* OK, maybe this should just be deleted, and use
regs->bp directly in code*/
static inline unsigned long frame_pointer(struct pt_regs *regs)
{
return regs->bp;
}

static inline unsigned long stack_pointer(struct pt_regs *regs)
{
#ifdef CONFIG_X86_32
return (unsigned long)regs;
#else
return regs->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)

Harvey



\
 
 \ /
  Last update: 2008-01-18 00:29    [W:0.060 / U:1.444 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site