This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [RFC -mm][PATCH 5/6] prepare kprobes code for x86 unification
- From: Jim Keniston <jkenisto at us dot ibm dot com>
- To: Masami Hiramatsu <mhiramat at redhat dot com>
- Cc: Arjan van de Ven <arjan at infradead dot org>, ananth at in dot ibm dot com, Roland McGrath <roland at redhat dot com>, prasanna at in dot ibm dot com, anil dot s dot keshavamurthy at intel dot com, davem at davemloft dot net, systemtap-ml <systemtap at sources dot redhat dot com>
- Date: Tue, 11 Dec 2007 10:39:22 -0800
- Subject: Re: [RFC -mm][PATCH 5/6] prepare kprobes code for x86 unification
- References: <475DC362.9000707@redhat.com> <20071211080259.0877708c@laptopd505.fenrus.org> <475EBD9B.2050504@redhat.com>
On Tue, 2007-12-11 at 11:40 -0500, Masami Hiramatsu wrote:
> Hi Arjan,
>
> Thank you for comment.
> Arjan van de Ven wrote:
> > On Mon, 10 Dec 2007 17:53:22 -0500
> > Masami Hiramatsu <mhiramat@redhat.com> wrote:
> >> +#define stack_addr(regs) ((unsigned long *)®s->sp)
> >
> > Hi,
> >
> > thanks for taking up this work again, however this line has a bug (yes it's a bug in the 32 bit retprobes);
> > the address of the stack is regs->sp not ®s->sp, since ®s->sp is the address of the
> > memory we store the stackpointer in, not the actual address on the stack...
>
> As far as I know, it is true on x86-64, but it's not true on x86-32(kernel mode).
> I checked it in __show_registers()@arch/x86/kernel/process_32.c.
>
> Here is that code:
> > if (user_mode_vm(regs)) {
> > sp = regs->sp;
> > ss = regs->ss & 0xffff;
> > savesegment(gs, gs);
> > } else {
> > sp = (unsigned long) (®s->sp);
> > savesegment(ss, ss);
> > savesegment(gs, gs);
> > }
>
> So, in kernel mode, ®s->sp is the address of the top of stack.
>
> Best Regards,
>
> >
> > Greetings,
> > Arjan van de Ven
Masami is correct. x86_32 CPUs don't save the ss and esp registers if
the CPU is already in kernel mode when it traps. So in this case,
regs->esp and regs->xss are not the [nonexistent] saved stack pointer
and ss register, but rather the last 8 bytes of the pre-int3 stack. So
®s->esp happens to point to the top of the pre-int3 stack.
Jim