Harvey Harrison wrote:
What do you think of:
/*
* (unsigned long)regs looks strange, 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 ®s happens to be esp. Valid only for kernel-mode
* pt_regs.
*/
sta
On Thu, 2008-01-17 at 20:36 -0500, H. Peter Anvin wrote:
> Roland McGrath wrote:
> > It's indeed true that &pt_regs is truly the esp value for x86-32
> > kernel-mode trap frames. Because this nonobvious calculation is
> > only right for a kernel mode pt_regs and not for a user-mode one,
> > I thi
On Thu, 2008-01-17 at 20:36 -0500, H. Peter Anvin wrote:
> Roland McGrath wrote:
> > It's indeed true that &pt_regs is truly the esp value for x86-32
> > kernel-mode trap frames. Because this nonobvious calculation is
> > only right for a kernel mode pt_regs and not for a user-mode one,
> > I thi
Roland McGrath wrote:
It's indeed true that &pt_regs is truly the esp value for x86-32
kernel-mode trap frames. Because this nonobvious calculation is
only right for a kernel mode pt_regs and not for a user-mode one,
I think it would be better to use a name for the inline/macro that
makes this
It's indeed true that &pt_regs is truly the esp value for x86-32
kernel-mode trap frames. Because this nonobvious calculation is
only right for a kernel mode pt_regs and not for a user-mode one,
I think it would be better to use a name for the inline/macro that
makes this quite clear, rather than
On Thu, 2008-01-17 at 20:14 -0500, H. Peter Anvin wrote:
> Harvey Harrison wrote:
> >
> >>> /* 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...
> >
>
Harvey Harrison wrote:
/* 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.
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 t
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
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 re
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. g
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.
-hpa
--
To unsubscribe from th
12 matches
Mail list logo
