This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: stack_used() not accurate?


On Mon, Jun 2, 2008 at 5:44 PM, Jim Keniston <jkenisto@us.ibm.com> wrote:
> On Mon, 2008-06-02 at 17:23 -0400, Mike Snitzer wrote:
>> On Mon, Jun 2, 2008 at 4:29 PM, Frank Ch. Eigler <fche@redhat.com> wrote:
> ...
>> >>
>> >> So, given that the calculated "free" is incorrect, this says to me
>> >> that the incorrect value is getting stored in CONTEXT->regs->esp on
>> >> x86 (or the value is stale)?
>> >
>> > Why do you think the latter is incorrect?  The asm "esp"-related one
>> > should give you the stack pointer at the moment of the probe handler
>> > execution.  The CONTEXT->regs->esp value should give the stack pointer
>> > at the moment of the probe hit - displaced in time (earlier) and
>> > potentially in space (different stack).  This is the dimension of
>> > imagination.  It is an area which we call the twilight zone.
>>
>> I understand that CONTEXT->regs->esp has the properties you described;
>> completely explains why it is so important to use CONTEXT->regs.  But
>> the problem, on x86, is that if I use CONTEXT->regs->esp I get a
>> negative values for "free" or <100 Bytes free.  I know that not to be
>> the case...
>>
>> Mike
>
> 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 &regs->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...


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]