How can i read the stack frames of running process?

Discussion in 'C Programming' started by harshal, Oct 17, 2007.

  1. harshal

    harshal Guest

    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, Oct 17, 2007
    #1
    1. Advertising

  2. harshal

    Richard Bos Guest

    harshal <> 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.
     
    Richard Bos, Oct 17, 2007
    #2
    1. Advertising

  3. On Oct 17, 3:56 pm, harshal <> 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
     
    karthikbalaguru, Oct 17, 2007
    #3
  4. harshal

    harshal Guest

    On Oct 17, 4:09 pm, (Richard Bos) wrote:
    > harshal <> 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
     
    harshal, Oct 17, 2007
    #4
  5. harshal

    cr88192 Guest

    "Richard Bos" <> wrote in message
    news:4all.nl...
    > harshal <> 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.
     
    cr88192, Oct 17, 2007
    #5
  6. On Oct 17, 3:56 pm, harshal <> 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, Oct 17, 2007
    #6
  7. harshal

    Mark Bluemel Guest

    karthikbalaguru wrote:
    > On Oct 17, 3:56 pm, harshal <> 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...
     
    Mark Bluemel, Oct 17, 2007
    #7
  8. harshal

    Mark Bluemel Guest

    harshal wrote:
    > On Oct 17, 4:09 pm, (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.
     
    Mark Bluemel, Oct 17, 2007
    #8
  9. On Oct 17, 3:56 pm, harshal <> 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
     
    karthikbalaguru, Oct 17, 2007
    #9
  10. On Oct 17, 3:56 pm, harshal <> 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
     
    karthikbalaguru, Oct 17, 2007
    #10
  11. harshal <> wrote:
    > On Oct 17, 4:09 pm, (Richard Bos) wrote:
    >> harshal <> 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
     
    Erik Trulsson, Oct 17, 2007
    #11
  12. On Oct 17, 3:56 pm, harshal <> 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, Oct 17, 2007
    #12
  13. harshal

    CBFalconer Guest

    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
     
    CBFalconer, Oct 17, 2007
    #13
  14. harshal

    CBFalconer Guest

    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
     
    CBFalconer, Oct 17, 2007
    #14
  15. harshal <> 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
     
    Chip Coldwell, Oct 17, 2007
    #15
  16. 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, Oct 17, 2007
    #16
  17. harshal

    Mark Bluemel Guest

    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, Oct 17, 2007
    #17
  18. 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, Oct 17, 2007
    #18
  19. harshal

    Mark Bluemel Guest

    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/comp.lang.c/msg/6eabb500fc06fcb3

    That's put me right... Neither __FUNCTION__ or __func__ are, strictly
    speaking, macros...
     
    Mark Bluemel, Oct 17, 2007
    #19
  20. "Philip Potter" <> schrieb im Newsbeitrag
    news:ff5aea$g83$...
    > 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
     
    Joachim Schmitz, Oct 17, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Jona
    Replies:
    2
    Views:
    830
  2. John English
    Replies:
    0
    Views:
    5,268
    John English
    Nov 7, 2005
  3. Surinder Singh
    Replies:
    1
    Views:
    1,237
    Richard Bos
    Dec 20, 2007
  4. David Banks
    Replies:
    5
    Views:
    297
    Peter Otten
    Oct 5, 2012
  5. Victor Hooi
    Replies:
    1
    Views:
    147
    Nobody
    Feb 10, 2013
Loading...

Share This Page