Hi all,

Can we read the stack frame's of the current process.
as we know that whenever a function call is made in c new functions
stack frame
is created and pushed on to the stack. and when the function returns
it is popped out from the stack. i want to know the caller functions
name.

i mean i want something like this

int a()
{
printf("File = %s\n",__FILE__);
/* i want to print the callers name over here. something like this
printf("Caller function = %s\n",__CALLER_FUN__); it should print
b*/
return 0;
}

int b()
{
a();
return 0;
}

int main()
{
b();
}

if there is any way please tell me.

Thanks and Regards
Harshal Shete

harshal <harshalshete@gmail.com> wrote:

> Can we read the stack frame's of the current process.

In reliable ISO C, you don't even know that you have something called a
"current process"[1], nor a "stack frame", let alone anything that is in
this stack frame's possession. All these details are system-specific,
all functions to read them are necessarily also system-specific, and in
all probability, old systems make doing so a brittle, unreliable process
while more modern systems (wisely) forbid you to put your grubby mitts
inside the running program's data without pre-arranged permission.

> as we know that whenever a function call is made in c new functions
> stack frame is created and pushed on to the stack.

You may think you know that; I think you merely suspect it.

> i want to know the caller functions name.

Pass it. Don't rely on dangerous, unportable, and dirty hackery.

(BTW: in English, the first person singular personal pronoun is
capitalised, except by pretentious bankers like E.E. Cummings.)

> if there is any way please tell me.

There is no way that I would trust with my computer's mental health.

Richard

[1] Unless you touch a live wire.

On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.com> wrote:
> Hi all,
>
> Can we read the stack frame's of the current process.
> as we know that whenever a function call is made in c new functions
> stack frame
> is created and pushed on to the stack. and when the function returns
> it is popped out from the stack. i want to know the caller functions
> name.
>
> i mean i want something like this
>
> int a()
> {
> printf("File = %s\n",__FILE__);
> /* i want to print the callers name over here. something like this
> printf("Caller function = %s\n",__CALLER_FUN__); it should print
> b*/
> return 0;
>
> }
>
> int b()
> {
> a();
> return 0;
>
> }
>
> int main()
> {
> b();
>
> }
>
> if there is any way please tell me.
>

You need to understand the architecture of your system, assembly,
compiler very well.
Write a logic in such a way that, you
try parsing throught the generated assembly file and get to know the
function that is calling it.
In the case of M68K there will be something like
JSR _a inside 'b' function.

Karthik Balaguru

On Oct 17, 4:09 pm, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> harshal <harshalsh...@gmail.com> wrote:
> > Can we read the stack frame's of the current process.
>
> In reliable ISO C, you don't even know that you have something called a
> "current process"[1], nor a "stack frame", let alone anything that is in
> this stack frame's possession. All these details are system-specific,
> all functions to read them are necessarily also system-specific, and in
> all probability, old systems make doing so a brittle, unreliable process
> while more modern systems (wisely) forbid you to put your grubby mitts
> inside the running program's data without pre-arranged permission.
>
> > as we know that whenever a function call is made in c new functions
> > stack frame is created and pushed on to the stack.
>
> You may think you know that; I think you merely suspect it.
>
> > i want to know the caller functions name.
>
> Pass it. Don't rely on dangerous, unportable, and dirty hackery.
>
> (BTW: in English, the first person singular personal pronoun is
> capitalised, except by pretentious bankers like E.E. Cummings.)
>
> > if there is any way please tell me.
>
> There is no way that I would trust with my computer's mental health.
>
> Richard
>
> [1] Unless you touch a live wire.

Can you please explain this in simple words.
from what you are saying it looks like it is nearly impossible.

but my question is that if a function can print its name with
__FUNCTION__
macro then why it can not print its callers name.
then what harm is there with printing its callers name ?

actually i thought of this thing because i want to resolve some memory
leak issues.
and for that purpose i was thinking to print the callers name in
kmalloc.
by the way i am using eCos as operating system.

Thanks and Regards
Harshal

"Richard Bos" <rlb@hoekstra-uitgeverij.nl> wrote in message
news:4715ebfc.158034270@news.xs4all.nl...
> harshal <harshalshete@gmail.com> wrote:
>
>> Can we read the stack frame's of the current process.
>
> In reliable ISO C, you don't even know that you have something called a
> "current process"[1], nor a "stack frame", let alone anything that is in
> this stack frame's possession. All these details are system-specific,
> all functions to read them are necessarily also system-specific, and in
> all probability, old systems make doing so a brittle, unreliable process
> while more modern systems (wisely) forbid you to put your grubby mitts
> inside the running program's data without pre-arranged permission.
>

now, this is curious:
I personally do not know of any arch requiring "pre-arranged permission to
put one's grubby mitts in the program's data".

there are a lot of things generally prevented by the OS and hardware, but I
have not heard of this one...


unless of course, by 'pre-arranged permission' you mean 'have to write stuff
in assembler...'.
well, this is true. now, the fun part, is getting the name for the
address...


>> as we know that whenever a function call is made in c new functions
>> stack frame is created and pushed on to the stack.
>
> You may think you know that; I think you merely suspect it.
>

yes, plausible. there is little requiring C compilers, for example, to not
perform inlining, tail-call optimization, and other such tricks...


>> i want to know the caller functions name.
>
> Pass it. Don't rely on dangerous, unportable, and dirty hackery.
>

unless you want to be like me and write your own dynamic compiler framework,
where one comes face to face with this kind of ugly and unportable
hackerry...


now, it is the case, that there is probably no simple answer here either, as
nearly any attempt at an answer would likely also require that the reader
understand what all is going on here.

On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.com> wrote:
> Hi all,
>
> Can we read the stack frame's of the current process.
> as we know that whenever a function call is made in c new functions
> stack frame
> is created and pushed on to the stack. and when the function returns
> it is popped out from the stack. i want to know the caller functions
> name.
>
> i mean i want something like this
>
> int a()
> {
> printf("File = %s\n",__FILE__);
> /* i want to print the callers name over here. something like this
> printf("Caller function = %s\n",__CALLER_FUN__); it should print
> b*/
> return 0;
>
> }
>
> int b()
> {
> a();
> return 0;
>
> }
>
> int main()
> {
> b();
>
> }
>
> if there is any way please tell me.
>

You can write some methods based on the MAP file created by Linker and
also using the assembly listing.

Karthik Balaguru

karthikbalaguru wrote:
> On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.com> wrote:
>> Hi all,
>>
>> Can we read the stack frame's of the current process.
....
> You can write some methods based on the MAP file created by Linker and
> also using the assembly listing.

I think it's unlikely that anyone capable of doing this would need to
post the question...

harshal wrote:
> On Oct 17, 4:09 pm, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:

> Can you please explain this in simple words.
OK - simple words follow:-

It is very difficult to do in any particular implementation.

It is impossible to produce a general solution.

> from what you are saying it looks like it is nearly impossible.

That's about right.

> but my question is that if a function can print its name with
> __FUNCTION__
> macro then why it can not print its callers name.

The __FUNCTION__ macro is handled by the preprocessor and is simply a
textual replacement at compile time. It's not (terribly) difficult for
the preprocessor to track which function it's processing at a time.

> actually i thought of this thing because i want to resolve some memory
> leak issues.

It can be a useful approach. But unless someone else has already
implemented it, it won't be at all easy...

> and for that purpose i was thinking to print the callers name in
> kmalloc.

I've never heard of kmalloc...

> by the way i am using eCos as operating system.

Then perhaps you could ask in a newsgroup or forum related to that
operating system.

On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.com> wrote:
> Hi all,
>
> Can we read the stack frame's of the current process.
> as we know that whenever a function call is made in c new functions
> stack frame
> is created and pushed on to the stack. and when the function returns
> it is popped out from the stack. i want to know the caller functions
> name.
>
> i mean i want something like this
>
> int a()
> {
> printf("File = %s\n",__FILE__);
> /* i want to print the callers name over here. something like this
> printf("Caller function = %s\n",__CALLER_FUN__); it should print
> b*/
> return 0;
>
> }
>
> int b()
> {
> a();
> return 0;
>
> }
>
> int main()
> {
> b();
>
> }
>
> if there is any way please tell me.
>

You can try something as below :
( This is just a rough idea for you . )

You need to know the register that has the address of the current
frame info.
and that address is normally saved to the frame by the called
function.

Create a LIFO list with this info
a) address of the calling function frame
b) return address
c) parameter list

Every function call should add a frame to the list.
Every return from function will delete the frame.

So, if you know the register that has the address of the current frame
info and the
value at that register, then you can make it up on your own.

Also , Many ways are dependent on parsing through the assembly files
and MAP files .

Karthik Balaguru

On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.com> wrote:
> Hi all,
>
> Can we read the stack frame's of the current process.
> as we know that whenever a function call is made in c new functions
> stack frame
> is created and pushed on to the stack. and when the function returns
> it is popped out from the stack. i want to know the caller functions
> name.
>
> i mean i want something like this
>
> int a()
> {
> printf("File = %s\n",__FILE__);
> /* i want to print the callers name over here. something like this
> printf("Caller function = %s\n",__CALLER_FUN__); it should print
> b*/
> return 0;
>
> }
>
> int b()
> {
> a();
> return 0;
>
> }
>
> int main()
> {
> b();
>
> }
>
> if there is any way please tell me.
>



You can try something as below :
( This is just a rough idea for you . )

You need to know the system architecture very well for this.

You need to know the register that has the address of the current
frame info.
and that address is normally saved to the frame by the called
function.

Create a LIFO list with info something as below such as for Every
function call that will add a frame to the list.
and for every return from function, it will delete the frame.
a) address of the calling function frame
b) return address
c) parameter list

So, if you know the register that has the address of the current frame
info and the
value at that register, then you can make it up on your own.

Also , Many ways are dependent on parsing through the assembly files
and MAP files .

Karthik Balaguru

harshal <harshalshete@gmail.com> wrote:
> On Oct 17, 4:09 pm, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
>> harshal <harshalsh...@gmail.com> wrote:
>> > Can we read the stack frame's of the current process.
>>
>> In reliable ISO C, you don't even know that you have something called a
>> "current process"[1], nor a "stack frame", let alone anything that is in
>> this stack frame's possession. All these details are system-specific,
>> all functions to read them are necessarily also system-specific, and in
>> all probability, old systems make doing so a brittle, unreliable process
>> while more modern systems (wisely) forbid you to put your grubby mitts
>> inside the running program's data without pre-arranged permission.
>>
>> > as we know that whenever a function call is made in c new functions
>> > stack frame is created and pushed on to the stack.
>>
>> You may think you know that; I think you merely suspect it.
>>
>> > i want to know the caller functions name.
>>
>> Pass it. Don't rely on dangerous, unportable, and dirty hackery.
>>
>> (BTW: in English, the first person singular personal pronoun is
>> capitalised, except by pretentious bankers like E.E. Cummings.)
>>
>> > if there is any way please tell me.
>>
>> There is no way that I would trust with my computer's mental health.
>>
>> Richard
>>
>> [1] Unless you touch a live wire.
>
> Can you please explain this in simple words.
> from what you are saying it looks like it is nearly impossible.
>
> but my question is that if a function can print its name with
> __FUNCTION__
> macro then why it can not print its callers name.
> then what harm is there with printing its callers name ?

Because the compiler knows at compile time which function it is compiling
and can replace __FUNCTION__ with a string containing that name.

At run-time there is no portable way of finding out even which function
you are in, much less which one you were called from.


Often all information about the names of functions and variables are
discarded by the compiler or linker when that information is no longer needed.

Sometimes a function do not have a stack frame of their own (even in systems
that use an ordinary stack.) Examples of this are functions that have been
inlined or a leaf-function (a function which does not call any other
function) that gets all its parameters (including the return address) passed
in registers.

And even if you do have a stackframe, and even if the information about the
names of functions is retained by the compiler, then the format of this stack frame
will be entirely system-dependent.

In short there is no way that is even half-way portable for a function to
find out which function it was called from.



If you really want to know the code-flow you will have to modify the source
code and insert a printf() (or equivalent) before each call to the function
you are interested in.





--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se

On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.com> wrote:
> Hi all,
>
> Can we read the stack frame's of the current process.
> as we know that whenever a function call is made in c new functions
> stack frame
> is created and pushed on to the stack. and when the function returns
> it is popped out from the stack. i want to know the caller functions
> name.
>
> i mean i want something like this
>
> int a()
> {
> printf("File = %s\n",__FILE__);
> /* i want to print the callers name over here. something like this
> printf("Caller function = %s\n",__CALLER_FUN__); it should print
> b*/
> return 0;
>
> }
>
> int b()
> {
> a();
> return 0;
>
> }
>
> int main()
> {
> b();
>
> }
>
> if there is any way please tell me.
>

kmalloc comes from linux. I think, gdb has good provisions w.r.t stack
frame .
There are many ways to print information about the selected stack
frame using gdb.

Karthik Balaguru

karthikbalaguru wrote:
>
.... snip ...
>
> You can write some methods based on the MAP file created by Linker
> and also using the assembly listing.

Please tell us exactly where the C standard discusses the MAP file,
or the action of the Linker. Also where it discusses 'the assembly
listing'.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com

karthikbalaguru wrote:
>
.... snip ...
>
> kmalloc comes from linux. I think, gdb has good provisions w.r.t
> stack frame . There are many ways to print information about the
> selected stack frame using gdb.

The subject of this newsgroup is the C language, as specified in
the various (current and past) C standards. None of kmalloc,
linux, gdb, stack frame, have ever appeared or been specified in
any C standard, and are all off-topic and system dependent here.
Note the 'system dependent'. That means such discussions are not
general to all C systems, and thus are not suitable for this
newsgroup.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>


--
Posted via a free Usenet account from http://www.teranews.com

harshal <harshalshete@gmail.com> writes:

> and for that purpose i was thinking to print the callers name in
> kmalloc.

Just insert a call dump_stack(); you'll get everything.

Chip

--
Charles M. "Chip" Coldwell
"Turn on, log in, tune out"
Somerville, Massachusetts, New England

Mark Bluemel wrote:
> harshal wrote:
>> but my question is that if a function can print its name with
>> __FUNCTION__
>> macro then why it can not print its callers name.
>
> The __FUNCTION__ macro is handled by the preprocessor and is simply a
> textual replacement at compile time. It's not (terribly) difficult for
> the preprocessor to track which function it's processing at a time.

I can't find any mention of __FUNCTION__ in n1256. I *can* find
__func__. Is __FUNCTION__ at all standard?

--
Philip Potter pgp <at> doc.ic.ac.uk

Philip Potter wrote:
> Mark Bluemel wrote:
>> harshal wrote:
>>> but my question is that if a function can print its name with
>>> __FUNCTION__
>>> macro then why it can not print its callers name.
>>
>> The __FUNCTION__ macro is handled by the preprocessor and is simply a
>> textual replacement at compile time. It's not (terribly) difficult for
>> the preprocessor to track which function it's processing at a time.
>
> I can't find any mention of __FUNCTION__ in n1256. I *can* find
> __func__. Is __FUNCTION__ at all standard?

It doesn't matter - the point that needed to be made to the OP was that
macros are processed by the precompiler. The guy didn't need (as far as
I can see) to worry about whether the particular macro he was referring
to was part of the standard.

Mark Bluemel wrote:
> Philip Potter wrote:
>> Mark Bluemel wrote:
>>> harshal wrote:
>>>> but my question is that if a function can print its name with
>>>> __FUNCTION__
>>>> macro then why it can not print its callers name.
>>>
>>> The __FUNCTION__ macro is handled by the preprocessor and is simply a
>>> textual replacement at compile time. It's not (terribly) difficult
>>> for the preprocessor to track which function it's processing at a time.
>>
>> I can't find any mention of __FUNCTION__ in n1256. I *can* find
>> __func__. Is __FUNCTION__ at all standard?
>
> It doesn't matter - the point that needed to be made to the OP was that
> macros are processed by the precompiler. The guy didn't need (as far as
> I can see) to worry about whether the particular macro he was referring
> to was part of the standard.

Yes, that's why I replied to you and not to him. I wasn't nitpicking, I
was asking a question, because I'm not certain enough of Acrobat's
searching functionality to be sure that __FUNCTION__ isn't in there.

--
Philip Potter pgp <at> doc.ic.ac.uk

Philip Potter wrote:
> Mark Bluemel wrote:
>> Philip Potter wrote:

>>> I can't find any mention of __FUNCTION__ in n1256. I *can* find
>>> __func__. Is __FUNCTION__ at all standard?
>>
>> It doesn't matter - the point that needed to be made to the OP was
>> that macros are processed by the precompiler. The guy didn't need (as
>> far as I can see) to worry about whether the particular macro he was
>> referring to was part of the standard.
>
> Yes, that's why I replied to you and not to him. I wasn't nitpicking, I
> was asking a question, because I'm not certain enough of Acrobat's
> searching functionality to be sure that __FUNCTION__ isn't in there.

I'm fairly sure this was discussed sometime ago. __FUNCTION__ is a
gcc-specific macro, I thought...

A quick google finds for example -
http://groups.google.co.uk/group/com...abb500fc06fcb3

That's put me right... Neither __FUNCTION__ or __func__ are, strictly
speaking, macros...

"Philip Potter" <pgp@see.sig.invalid> schrieb im Newsbeitrag
news:ff5aea$g83$3@aioe.org...
> Mark Bluemel wrote:
>> Philip Potter wrote:
>>> Mark Bluemel wrote:
>>>> harshal wrote:
>>>>> but my question is that if a function can print its name with
>>>>> __FUNCTION__
>>>>> macro then why it can not print its callers name.
>>>>
>>>> The __FUNCTION__ macro is handled by the preprocessor and is simply a
>>>> textual replacement at compile time. It's not (terribly) difficult for
>>>> the preprocessor to track which function it's processing at a time.
>>>
>>> I can't find any mention of __FUNCTION__ in n1256. I *can* find
>>> __func__. Is __FUNCTION__ at all standard?
>>
>> It doesn't matter - the point that needed to be made to the OP was that
>> macros are processed by the precompiler. The guy didn't need (as far as I
>> can see) to worry about whether the particular macro he was referring to
>> was part of the standard.
>
> Yes, that's why I replied to you and not to him. I wasn't nitpicking, I
> was asking a question, because I'm not certain enough of Acrobat's
> searching functionality to be sure that __FUNCTION__ isn't in there.
__func__ is not a marco

The identifier __func_ _ shall be implicitly declared by the translator as
if,

immediately following the opening brace of each function definition, the
declaration

static const char _ _func_ _[] = "function-name";

appeared, where function-name is the name of the lexically-enclosing
function.61)



Bye, Jojo

On Oct 17, 2:15 pm, karthikbalaguru <karthikbalagur...@gmail.com>
wrote:
> On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.com> wrote:
>
> > Can we read the stack frame's of the current process.
>
> kmalloc comes from linux.

Nonsense. It no more comes from Linux than from eCos.

On Oct 17, 3:56 pm, harshal <harshalsh...@gmail.com> wrote:
> Hi all,
>
> Can we read the stack frame's of the current process.
> as we know that whenever a function call is made in c new functions
> stack frame
> is created and pushed on to the stack. and when the function returns
> it is popped out from the stack. i want to know the caller functions
> name.

It can be done, but you need to understand your complete system
architecture properly.
What is the architecture you are working on ?

You can also do that by parsing the assembly code generated by your
compiler for that program.
For example in your case, w.r.t M68K family, you need to find the
location for the presence of the following which would give you the
answer as function 'b'.
JSR _a

Karthik Balaguru


Karthik Balaguru

Mark Bluemel <mark_bluemel@pobox.com> writes:
[...]
> That's put me right... Neither __FUNCTION__ or __func__ are, strictly
> speaking, macros...

Correct.

__FUNCTION__ is non-standard, but is provided by gcc as an extension.
In older versions of gcc, it's a "magic identifier" which is replaced
by a string literal; it could concatenated as if it were a literal,
but it didn't work with #ifdef. In newer versions of gcc, it's simply
another name for __func__.

__func__ is standard in C99, but didn't exist in C90 (though of course
a C90 compiler could provide it as an extension). It acts as if it
were declared as a static const char[] immediately following the
opening brace of the function definition.

If you think about it, __FUNCTION__ or __func__ can't be a macro,
since the preprocessor (more precisely, translation phase 4, which
handles macro expansion) runs before function definitions have been
processed.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Chip Coldwell <coldwell@gmail.invalid> writes:
> harshal <harshalshete@gmail.com> writes:
>> and for that purpose i was thinking to print the callers name in
>> kmalloc.
>
> Just insert a call dump_stack(); you'll get everything.

Presumably implementing dump_stack() is left as an exercise. (There's
no such function in standard C, and there's no portable way of
implementing it; for a given implementation, there may not even be a
non-portable way of implementing it.)

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Philip Potter wrote:
> Mark Bluemel wrote:
>> Philip Potter wrote:
>>> Mark Bluemel wrote:
>>>> harshal wrote:
>>>>
>>>>> but my question is that if a function can print its name with
>>>>> __FUNCTION__
>>>>> macro then why it can not print its callers name.
>>>>
>>>> The __FUNCTION__ macro is handled by the preprocessor and is
>>>> simply a textual replacement at compile time. It's not
>>>> (terribly) difficult for the preprocessor to track which
>>>> function it's processing at a time.
>>>
>>> I can't find any mention of __FUNCTION__ in n1256. I *can* find
>>> __func__. Is __FUNCTION__ at all standard?
>>
>> It doesn't matter - the point that needed to be made to the OP
>> was that macros are processed by the precompiler. The guy didn't
>> need (as far as I can see) to worry about whether the particular
>> macro he was referring to was part of the standard.
>
> Yes, that's why I replied to you and not to him. I wasn't
> nitpicking, I was asking a question, because I'm not certain
> enough of Acrobat's searching functionality to be sure that
> __FUNCTION__ isn't in there.

One more reason to use the text version of N869. There is no
__FUNCTION__. However, __func__ does exist.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>



--
Posted via a free Usenet account from http://www.teranews.com