Date: | Wed, 26 Apr 2006 09:51:35 +0300 |
From: | Diomidis Spinellis <dds@aueb.gr> |
Organization: | Athens University of Economics and Business |
User-Agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.2) Gecko/20060404 SeaMonkey/1.0.1 |
MIME-Version: | 1.0 |
Newsgroups: | comp.lang.c++ |
Subject: | Re: obtaining callstack level |
References: | <1145929379.611965.199020@t31g2000cwb.googlegroups.com> <e2kgju$60a$1@volcano1.grnet.gr> <4b7k96F1001rsU1@individual.net> |
In-Reply-To: | <4b7k96F1001rsU1@individual.net> |
Content-Type: | text/plain; charset=ISO-8859-1; format=flowed |
Content-Transfer-Encoding: | 7bit |
Ian Collins wrote: > Diomidis Spinellis wrote: >> seannakasone@yahoo.com wrote: >> >>> Is there a way to get the callstack level in c++? for example, take >>> the following code: >> >> [...] >> >>> And I don't mean obtaining it from using a debugger and looking at the >>> callstack. I'm mean obtaining it programmatically. >> >> If you're not interested in a precise number, but can accept a measure >> that would indicate the stack depth in bytes you can obtain the address >> of one of the function's plain local variables through the & operator >> and cast it to a char * pointer. I've used this technique to track the >> use of stack space during the runtime of a program; see the snapshots at >> <http://www.spinellis.gr/codequality/stack.gif?clcpp>. This technique >> is not portable, but will work on most computer architectures. > > Do you get artificially high values? > > I was thinking of the case where the compiler could use registers for > local variables. Until you start taking their address which would > defeat that optimisation. I assume by "high values" you mean high memory addresses, i.e. low stack usage values. At most the measure will be off by the number of the processor's registers, because even when the compiler allocates local variables to registers these have to be stored on the stack when another function gets called. In the particular case I wanted to profile the stack's growth across millions of function invocations; an offset of a few tens of bytes would hardly matter. Function inlining is also affecting the results (I used a modified call graph profiler function prologue to write the values to a file, so inlined functions weren't tracked at all.) -- Diomidis