J
J. J. Farrell
Nonsense. It no more comes from Linux than from eCos.
Nonsense. It no more comes from Linux than from eCos.
K
karthikbalaguru
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
K
Keith Thompson
Mark Bluemel said:
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.
K
Keith Thompson
Chip Coldwell said:
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.)
C
CBFalconer
Philip said:
One more reason to use the text version of N869. There is no
__FUNCTION__. However, __func__ does exist.
I
Iwo Mergler
harshal said:
As others pointed out, it's not a good idea, it's highly system
dependent. On many systems it is possible to read the address of
the call instruction (or the one after) from the stack. In order
to get the *name* of the calling function, you'll have to compare
that address with a address map of the application. This is what
debuggers do.
If you have full control over the source of the calling and the
called function, there is no need to mess with the stack. The
trick is to use a macro which passes __FUNCTION__ into the called
function as an argument.
Replace with this:
#define a(...) _a(__FUNCTION__)
int _a(const char *caller)
{
printf("Caller function = %s\n",caller);
return 0;
}
Kind regards,
Iwo
T
Tor Rustad
Philip Potter wrote:
__func__ is C99, __FUNCTION__ is *not*.
__func__ is C99, __FUNCTION__ is *not*.
T
Tor Rustad
harshal said:
This isn't an assembler programming group.
You know more than me... the C standard says nothing about *stack* or
*frame*.
If I needed this debug information, I would crate my own call three
tracker. First, two functions is needed:
void func_enter(const char *func_name);
void func_leave(void);
and to get the parent function, you could e.g. use a double-linked list
and call
const char *func_parent(void);
M
Mark McIntyre
I don't think thats an accurate comment. The text version is just as
capable of having __ FUNCTION __ as the PDF.
More of an issue is Philip's uncertainty as to how to use a search
function...
Hint: search for word fragments eg UNCTIO--
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
?
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F
The text version of N869 does not include any spacing in any of the 20
identifiers starting with __. There's no reason to assume that if one
more were mentioned, that one would.
M
Mark McIntyre
And you know this for sure, how exactly? Other than by searching for
it, I mean. .
Chuck was in my view unreasonably claiming that the PDF was inferior
to the text version due to lack of searchability. I merely wanted to
point out that this is a false inference.
--
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
?
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F
By also searching for any _ or __ as a separate word.
M
Mark McIntyre
I'm wondering which part of my last sentence was tricky to
understand....
--
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
?
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F
I'm wondering which part of my last sentence was tricky to
understand....
Well, what did you mean by "it" ? I was assuming your point was that
searching for "__func__" won't show you whether the text file also
contains "_ _func_ _" in other places. If your point was merely that it
is possible for a plain text file to contain "_ _func_ _", then you're
correct, of course, but I don't see why it matters once you know that
this one doesn't.
M
Mark McIntyre
*sigh*.
Its irrelevant what "it" is. Either the plaintext or the PDF can be
handily searched for whatever you want to. Obviously if there are
typos (I recall some bizarre diacritical being used occasionally, and
definitely some spaces where none should be), it makes searches harder
but this is not the fault of the file format. There is no intrinsic
reason (other than ludditism) to distrust either search facility.
--
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
C
CBFalconer
Mark said:
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.
?
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F
It doesn't have to be an intrinsic reason. The text version of n869 could
have contained spellings that cause problems for searching, but doesn't.
The PDF versions of standards' drafts do. What alternatives the formats
allow is irrelevant.
Let's go upthread and find the message you had a problem with:
[CBFalconer wrote:]
There is no claim that it is an inherent property of text files that they
will contain correct spellings. The text version of n869 happens to be
one that does contain correct spellings -- please don't start with "how
do you know?" again -- and for that reason searching it in produces
better results.
K
Keith Thompson
Harald van D©¦k said:
As far as I can tell, it has not yet been established that, for
example, n1256.pdf contains any incorrect spellings.
?
=?iso-2022-kr?q?=1B=24=29CHarald_van_D=0E=29=26=0F
From n869.txt, from the foreword:
-- __func__ predefined identifier
From n1256.pdf:
— _ _func_ _ predeï¬ned identiï¬er
C
Chris Hills
No, this is not always the case. It only happens on stack based systems.
Also some compilers don't use a stack even when the MCU does.
It will depend very much on the target MCU and the compiler used neither
of which you mentioned.