How can i read the stack frames of running process?

[harshal]

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

[Mark McIntyre]

On Mon, 22 Oct 2007 12:25:56 -0400, in comp.lang.c , Ernie Wright
<er****@comcast.netwrote:

>Mark McIntyre wrote:

>On Sun, 21 Oct 2007 11:00:37 -0400, in comp.lang.c , Ernie Wright
<er****@comcast.netwrote:

>>>Mark McIntyre wrote:

There is no intrinsic reason (other than ludditism) to distrust
either search facility.

It's not clear to me what you mean by "instrinsic" here.

intrinsic as in built in?

Well, yeah, but as opposed to what?

Sorry, but I pretty much assumed my audience could read english. Not
trying to be offensive, but I have no intention of defining what an
intrinsic property is.

>This falls under the heading of "ludditism"... :-)

Or Luddism, even. You say that like it's a bad thing.

From Wikipedia: An official announcement, 12th February 1811 "Any
person who breaks or destroys machinery in any mill used in the
preparing or spinning of wool or cotton or other material for the use
of the stocking or lace manufacture, on being lawfully convicted
.....shall suffer death."

Seems pretty bad to me...

>While there are different reasons why the plaintext search might fail.

There's no symmetry here. There are *more* reasons that a PDF search
might fail.

I disagree. There are *different* reasons.

>What, for example, do you think is going on in this search:

http://home.comcast.net/~erniew/images/pdfsearch.gif

*shrug*
Probably there's an embedded n-dash sized space in "angle".
Plaintext searches can and do fail for similar reasons - I've seen
searches fail because of embedded (invisible) characters outside the
range 32-127.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Mark McIntyre]

On Mon, 22 Oct 2007 05:38:50 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:

>The problem with the spellings in this thread was that you can't search
for __func__ and find where it's referenced. (Or more accurately, that
you can't search for __FUNCTION__ to find that it's not referenced.)

Perhaps not - but you can search for UNCTI, which is highly likely to
be unique.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[santosh]

Mark McIntyre wrote:

On Sat, 20 Oct 2007 18:09:04 -0400, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:

>>No, you misinterpret my comment. The point is that PDF searches
can only be done by a PDF reader. With text you have a choice,
such as grep, a text editor, or any other piece of text handling
software on your system. So you can suit your search methods to
software familiar to you.

Why would anyone under the age of 30 be familiar with arcane stuff
like grep?

People who read C Standards are not likely to be a "Joe" user,
notwithstanding their age.

<snip>

[Ben Bacarisse]

CBFalconer <cb********@yahoo.comwrites:

$)CHarald van D)&k wrote:

>Keith Thompson wrote:

>>As far as I can tell, it has not yet been established that, for
example, n1256.pdf contains any incorrect spellings.

From n869.txt, from the foreword:
-- __func__ predefined identifier

From n1256.pdf:
â

€
� _ _func_ _
predeï¬
identiï¬

[Richard Bos]

Mark McIntyre <ma**********@spamcop.netwrote:

On Mon, 22 Oct 2007 05:38:50 +0000 (UTC), in comp.lang.c , $)CHarald
van D)&k <tr*****@gmail.comwrote:

The problem with the spellings in this thread was that you can't search
for __func__ and find where it's referenced. (Or more accurately, that
you can't search for __FUNCTION__ to find that it's not referenced.)

Perhaps not - but you can search for UNCTI, which is highly likely to
be unique.

Or you could - perhaps? revolutionary idea, I know - check the index.
I know that this is the C Standard we're talking about, not the Perl...
erm... lack of any standard, but there _is_ more than one way to do it.

Richard

[CBFalconer]

Ben Bacarisse wrote:

CBFalconer <cb********@yahoo.comwrites:

.... snip ...

>

>The blanks between '_' chars are an effect of the font used. The
other anomaly is due to the use of some peculiar character to
represent the sequence 'fi'. So there are no incorrect spelling
identified, but one more of the penalties of .PDF publication is
exposed.

I disagree. From what I can see the "_ _" problem *is* a case of
incorrect spelling (but a well-intentioned one). It seems to have
been put in deliberately to make the double underscore obvious.
The "fi" ligature is simply correct and good quality PDF readers
will cut and paste it as "fi" (two characters) and match it in a
search for "f" followed by "i". In other words, it works just
fine.

I don't think either says anything about the penalty of PDF
publication. In fact for interactive (i.e. non scripted) searches
I like the PDF better, now. I can search for text, jump to
specific pages or go right to a given section just by typing any
part of the section number or name.

We'll just have to agree to disagree. My main point was that with
text you have no problem selecting the search software to suit your
tastes and needs.

--
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

[Mark McIntyre]

On Tue, 23 Oct 2007 06:14:22 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

>Or you could - perhaps? revolutionary idea, I know - check the index.

Typically, an index doesn't index every single word!

A - see pages 2-1200 inclusive.
But - see pages 2,3,4,5,6,7,8,11,12,14,16,....
for - see pages 2-1200 except 1104 and 896

--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Bos]

Mark McIntyre <ma**********@spamcop.netwrote:

On Tue, 23 Oct 2007 06:14:22 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

Or you could - perhaps? revolutionary idea, I know - check the index.

Typically, an index doesn't index every single word!

A - see pages 2-1200 inclusive.
But - see pages 2,3,4,5,6,7,8,11,12,14,16,....
for - see pages 2-1200 except 1104 and 896

Typically, one doesn't search for indefinite articles or coordinating
conjunctions. One searches for important nouns - precisely the ones that
are found in a good index. In this case, __func__ is in the index, while
__FUNCTION__ is not; one look at this index at the start of this whole
useless argument about PDF versus text versus underscores versus
identifiers would have settled the matter.

Richard

[Mark McIntyre]

On Fri, 26 Oct 2007 06:26:20 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

>In this case, __func__ is in the index, while
__FUNCTION__ is not; one look at this index at the start of this whole
useless argument about PDF versus text versus underscores versus
identifiers would have settled the matter.

I agree, but I think the point being made is that indices do not index
everything, and can thus only tell what _is_ in the book.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

[Richard Bos]

Mark McIntyre <ma**********@spamcop.netwrote:

rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

In this case, __func__ is in the index, while
__FUNCTION__ is not; one look at this index at the start of this whole
useless argument about PDF versus text versus underscores versus
identifiers would have settled the matter.

I agree, but I think the point being made is that indices do not index
everything, and can thus only tell what _is_ in the book.

A good index, which I think one should assume the Standard does have,
indexes everything important. Thus, if something is not in the
Standard's index, either it isn't in the Standard, or it's only
mentioned in passing. Since __func__ is in it but __FUNCTION__ is not...
draw your own conclusion.

Richard

[Mark McIntyre]

On Mon, 29 Oct 2007 13:26:40 GMT, in comp.lang.c ,
rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

>Mark McIntyre <ma**********@spamcop.netwrote:

>rl*@hoekstra-uitgeverij.nl (Richard Bos) wrote:

>In this case, __func__ is in the index, while
__FUNCTION__ is not; one look at this index at the start of this whole
useless argument about PDF versus text versus underscores versus
identifiers would have settled the matter.

I agree, but I think the point being made is that indices do not index
everything, and can thus only tell what _is_ in the book.

A good index,

....

>indexes everything important.

....

>Since __func__ is in it but __FUNCTION__ is not...
draw your own conclusion.

I agree, but its not a proof and cannot settle the matter.
--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan