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