process stack question

process stack question

[Robert Schweikert]

I have been searching for some documentation on how to get at
information regarding the process stack but I didn't find much and from
what I found it was not clear to me how I could use the information.

Here is what I am after.

We have some rudimentary memory tracking tools in our application and
I'd like to put some debug output in that allows me to write the name of
the routine I am in to some debug log.

My thinking is that I should be able to get a hold of the process call
stack and using the top of the stack I should have the name of the
function/method I am in. 

Any help on how to go about this would be appreciated. A pointer to any
documentation on how to get a hold of the stack, or the public API for
this is of course welcome.

Thanks,
Robert
-- 
Robert Schweikert <Robert.Schweikert@abaqus.com>
ABAQUS

Re: process stack question

[Paul Rolland]

Hello,

Have a look at this :

5.43 Getting the Return or Frame Address of a Function 
These functions may be used to get information about the callers of a function. 


Built-in Function: void * __builtin_return_address (unsigned int level) 
This function returns the return address of the current function, or of one of its callers. The level argument is number of frames
to scan up the call stack. A value of 0 yields the return address of the current function, a value of 1 yields the return address of
the caller of the current function, and so forth. 

The level argument must be a constant integer. 

On some machines it may be impossible to determine the return address of any function other than the current one; in such cases, or
when the top of the stack has been reached, this function will return 0 or a random value. In addition, __builtin_frame_address may
be used to determine if the top of the stack has been reached. 

This function should only be used with a nonzero argument for debugging purposes. 



Built-in Function: void * __builtin_frame_address (unsigned int level) 
This function is similar to __builtin_return_address, but it returns the address of the function frame rather than the return
address of the function. Calling __builtin_frame_address with a value of 0 yields the frame address of the current function, a value
of 1 yields the frame address of the caller of the current function, and so forth. 

The frame is the area on the stack which holds local variables and saved registers. The frame address is normally the address of the
first word pushed on to the stack by the function. However, the exact definition depends upon the processor and the calling
convention. If the processor has a dedicated frame pointer register, and the function has a frame, then __builtin_frame_address will
return the value of the frame pointer register. 

On some machines it may be impossible to determine the frame address of any function other than the current one; in such cases, or
when the top of the stack has been reached, this function will return 0 if the first frame pointer is properly initialized by the
startup code. 

This function should only be used with a nonzero argument for debugging purposes

Regards,
Paul


Paul Rolland, rol@witbe.net
Witbe.net SA
Directeur Associe

--

Please no HTML, I'm not a browser - Pas d'HTML, je ne suis pas un navigateur

"Some people dream of success... while others wake up and work hard at it"

> -----Original Message-----
> From: linux-kernel-owner@vger.kernel.org 
> [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of 
> Robert Schweikert
> Sent: Thursday, June 19, 2003 9:19 PM
> To: linux-kernel@vger.kernel.org
> Cc: Robert Schweikert
> Subject: process stack question
> 
> 
> I have been searching for some documentation on how to get at 
> information regarding the process stack but I didn't find 
> much and from what I found it was not clear to me how I could 
> use the information.
> 
> Here is what I am after.
> 
> We have some rudimentary memory tracking tools in our 
> application and I'd like to put some debug output in that 
> allows me to write the name of the routine I am in to some debug log.
> 
> My thinking is that I should be able to get a hold of the 
> process call stack and using the top of the stack I should 
> have the name of the function/method I am in. 
> 
> Any help on how to go about this would be appreciated. A 
> pointer to any documentation on how to get a hold of the 
> stack, or the public API for this is of course welcome.
> 
> Thanks,
> Robert
> -- 
> Robert Schweikert <Robert.Schweikert@abaqus.com>
> ABAQUS
> -
> To unsubscribe from this list: send the line "unsubscribe 
> linux-kernel" in the body of a message to 
> majordomo@vger.kernel.org More majordomo info at  
http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: process stack question

[Perez-Gonzalez, Inaky]

> From: Robert Schweikert [mailto:Robert.Schweikert@abaqus.com]
> 
> My thinking is that I should be able to get a hold of the process call
> stack and using the top of the stack I should have the name of the
> function/method I am in.

What about something like getting the value of the EIP at
that point (will require some assembly-fu, most probably) and 
calling the equivalent of:

$ addr2line -f -e my-program ADDR

#define _GNU_SOURCE
#include <stdio.h>

const char *program_name;

void some_function (void)
{
  int cnt = 0;
  unsigned long my_eip;
  char *command;
  
  for (cnt = 0; cnt < 10; cnt++) {
    printf ("%d ", cnt);
    fflush (stdout);
  }
  printf ("\n");
  asm volatile (
    "    call 2f               \n"
    "2:                        \n"
    "    pop %0                \n"
    : "=r" (my_eip));
  printf ("I am at 0x%lx\n", my_eip);
  asprintf (&command, "addr2line -f -e \"%s\" 0x%lx\n",
	    program_name, my_eip);
  system (command);
}

int main (int argc, char **argv) 
{
  program_name = argv[0];
  some_function();
  return 0;
}

Not the most elegant solution, but gives an idea. Surely you
can call the equivalent of addr2line by linking into libbfd.
YMMV.

Iñaky Pérez-González -- Not speaking for Intel -- all opinions are my own
(and my fault)