This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: stack_used() not accurate?
On Mon, Jun 2, 2008 at 7:06 PM, Jim Keniston <jkenisto@us.ibm.com> wrote:
> On Mon, 2008-06-02 at 18:27 -0400, Mike Snitzer wrote:
>> On Mon, Jun 2, 2008 at 5:44 PM, Jim Keniston <jkenisto@us.ibm.com> wrote:
> ...
>> >
>> > Sorry, I haven't been following this thread for a while, so maybe this
>> > has already been mentioned. But keep in mind that on i386, when your
>> > breakpoint trap happens in kernel code, esp and ss aren't saved on the
>> > stack. So regs->esp and regs->ss contain the top of the pre-trap stack,
>> > and the pre-trap stack pointer is ®s->esp, not regs->esp.
>>
>> OK, so something like this for x86?
>>
>> function stack_used_new:long() %{
>> long free = THREAD_SIZE;
>> if (CONTEXT->regs) {
>> long curbase = (long)task_stack_page(current);
>> long *sp = (long *) &(REG_SP(CONTEXT->regs));
>> free = (long)sp - (curbase + sizeof(struct thread_info));
>> }
>> THIS->__retvalue = THREAD_SIZE - free;
>> %}
>>
>> The results look much more like I'd expect...
>
> Your calculation of free looks correct (although I'd make sp a long
> rather than a long* to simplify things a bit).
Yes, just need a cast to (long), thanks.
> But your return value seems to include the size of the struct
> thread_info, which seems wrong. I'd think you'd want
> THIS->__retvalue = (curbase + THREAD_SIZE) - sp;
> or
> THIS->__retvalue = THREAD_SIZE - (sp & (THREAD_SIZE-1));
> That seems more in keeping with the original implementation.
Your 2nd suggestion always returns 4096. As for your main concern,
struct thread_info is a "used" portion of the stack isn't it?
Mike