trapping library calls

Discussion in 'C Programming' started by Keith Briggs, Oct 8, 2003.

  1. Keith Briggs

    Keith Briggs Guest

    How can I trap library calls, say to puts, and get them to call a puts
    function I write, which then performs some special action before calling the
    real puts from libc?
    I tried all kinds of special linker options, but it seems that when my puts
    calls the real puts, it actually calls itself and gets into an infinite
    loop. Is this kind of thing possible with the standard gcc and GNU ld
    tools?
    Thanks, Keith
     
    Keith Briggs, Oct 8, 2003
    #1
    1. Advertising

  2. Keith Briggs

    Richard Bos Guest

    "Keith Briggs" <> wrote:

    > How can I trap library calls, say to puts, and get them to call a puts
    > function I write, which then performs some special action before calling the
    > real puts from libc?


    Portably, you can't. You can #define puts() to be something else, or
    similar dirty tricks, but AFAIK they all invoke undefined behaviour, and
    thus may work or not.
    It's quite possible that your implementation does provide you with the
    option to do this, but it's not required to; ask in a newsgroup
    dedicated to your implementation.

    Richard
     
    Richard Bos, Oct 8, 2003
    #2
    1. Advertising

  3. Keith Briggs

    Dan Pop Guest

    In <bm12oe$l59$> "Keith Briggs" <> writes:

    >How can I trap library calls, say to puts, and get them to call a puts
    >function I write, which then performs some special action before calling the
    >real puts from libc?
    >I tried all kinds of special linker options, but it seems that when my puts
    >calls the real puts, it actually calls itself and gets into an infinite
    >loop. Is this kind of thing possible with the standard gcc and GNU ld
    >tools?


    It's not blessed by the C standard, but it should work:

    1. Write a header (say myputs.h) like this:

    #ifdef USE_MYPUTS
    int myputs(const char *s);
    #define puts myputs
    #endif

    This header will be included, *after* including <stdio.h>, in each
    source file that needs to have its puts calls trapped. Feel free to add
    guards against multiple inclusion, if you think it's worth it.

    2. Provide a definition for myputs, in one of the source files, like this:

    #include <stdio.h>

    #ifdef USE_MYPUTS
    int myputs(const char *s)
    {
    /* do whatever you need to do, including calling puts */
    }
    #endif

    #include "myputs.h"

    /* the rest of the code calling puts goes here */
    /* it will actually call myputs instead */

    Now, you can control the trapping of the puts calls by defining the
    USE_MYPUTS macro on the compiler command line.

    Strictly speaking, you're not allowed to define the puts macro after
    including <stdio.h>, but there should be no problems in practice: it is
    highly unlikely that other standard library macros used by your program
    contain puts calls.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Oct 8, 2003
    #3
  4. Keith Briggs

    Kris Wempa Guest

    "Keith Briggs" <> wrote in message
    news:bm12oe$l59$...
    > How can I trap library calls, say to puts, and get them to call a puts
    > function I write, which then performs some special action before calling

    the
    > real puts from libc?
    > I tried all kinds of special linker options, but it seems that when my

    puts
    > calls the real puts, it actually calls itself and gets into an infinite
    > loop. Is this kind of thing possible with the standard gcc and GNU ld
    > tools?
    > Thanks, Keith
    >
    >


    There are several ways this can be done. I'll assume that this is a
    temporary change and that you will eventually want to go back to calling the
    "real" puts(). You can use a preprocessor macro such as:

    #defined puts(X) my_puts(X)

    and then write a definition such as:

    int my_puts(const char *s)
    {
    /* Do all of your specific actions here */

    #undef puts
    puts(s); /* call the real puts() here */
    }

    If you do NOT plan on reverting to the original puts(), then just remove the
    #define and #undef macros and globally replace all the puts() calls with
    my_puts() calls. I hope that helps.
     
    Kris Wempa, Oct 8, 2003
    #4
  5. Keith Briggs

    Keith Briggs Guest

    Thank you for the suggestions, but I didn't make it clear in my original
    post that I do not have the source code. This needs to be done with an
    already compiled application.
    Keith

    "Richard Bos" <> wrote in message
    news:...
    > "Keith Briggs" <> wrote:
    >
    > > How can I trap library calls, say to puts, and get them to call a puts
    > > function I write, which then performs some special action before calling

    the
    > > real puts from libc?

    >
    > Portably, you can't. You can #define puts() to be something else, or
    > similar dirty tricks, but AFAIK they all invoke undefined behaviour, and
    > thus may work or not.
    > It's quite possible that your implementation does provide you with the
    > option to do this, but it's not required to; ask in a newsgroup
    > dedicated to your implementation.
    >
    > Richard
     
    Keith Briggs, Oct 8, 2003
    #5
  6. Keith Briggs

    Richard Bos Guest

    "Keith Briggs" <> wrote:

    [ Don't top-post, please. ]

    > Thank you for the suggestions, but I didn't make it clear in my original
    > post that I do not have the source code.


    In that case, you're up a creek.

    > This needs to be done with an already compiled application.


    And if this application is statically linked, you haven't got a paddle,
    either. Forget it. If it's dynamically linked, there _may_ be hope, but
    it would be highly risky and completely system-dependent and off-topic.

    Richard
     
    Richard Bos, Oct 8, 2003
    #6
  7. Keith Briggs

    Artie Gold Guest

    Keith Briggs wrote:
    > How can I trap library calls, say to puts, and get them to call a puts
    > function I write, which then performs some special action before calling the
    > real puts from libc?
    > I tried all kinds of special linker options, but it seems that when my puts
    > calls the real puts, it actually calls itself and gets into an infinite
    > loop. Is this kind of thing possible with the standard gcc and GNU ld
    > tools?
    > Thanks, Keith
    >
    >

    It is likely possible -- but not in standard C (making your question
    off topic here).

    Ask in a newsgroup devoted to your platform
    (news:comp.unix.programmer or news:gnu.gcc.help -- I'm guessing
    here) and all shall be revealed!

    HTH,
    --ag


    --
    Artie Gold -- Austin, Texas
    Oh, for the good old days of regular old SPAM.
     
    Artie Gold, Oct 8, 2003
    #7
  8. Keith Briggs

    CBFalconer Guest

    *** evil topposting fixed ***

    Keith Briggs wrote:
    > "Richard Bos" <> wrote in message
    > > "Keith Briggs" <> wrote:
    > >
    > > > How can I trap library calls, say to puts, and get them to
    > > > call a puts function I write, which then performs some special
    > > > action before calling the real puts from libc?

    > >
    > > Portably, you can't. You can #define puts() to be something
    > > else, or similar dirty tricks, but AFAIK they all invoke
    > > undefined behaviour, and thus may work or not.
    > > It's quite possible that your implementation does provide
    > > you with the option to do this, but it's not required to;
    > > ask in a newsgroup dedicated to your implementation.

    >
    > Thank you for the suggestions, but I didn't make it clear in
    > my original post that I do not have the source code. This
    > needs to be done with an already compiled application.


    Then this is not a C language question, but something specific to
    a system and implementation. Use of a debugger may help. At any
    rate, look for a newsgroup that deals with your system.

    When you find such, or if you come back here, do not top-post. It
    is generally considered rude. Your answers belong after the
    quoted material, or intermixed. Do snip out quoted portions that
    are not germane.

    --
    Chuck F () ()
    Available for consulting/temporary embedded and systems.
    <http://cbfalconer.home.att.net> USE worldnet address!
     
    CBFalconer, Oct 8, 2003
    #8
  9. "Keith Briggs" <> wrote in message
    news:bm1bsq$r7f$...
    > Thank you for the suggestions, but I didn't make it clear in my original
    > post that I do not have the source code. This needs to be done with an
    > already compiled application.


    As others have said, at that point it isn't a C question anymore.

    Assuming, though, that you consider an object file as a C binary file, which
    it may or may not be, depending on the implementation, then some things can
    be done in C.

    I have before written programs that will recognize a given series of bytes
    in a file and replace them with another set of bytes. (Assuming that the
    system is byte oriented.) If you do that you can, for example, change
    "puts" to "puty", or any other string of the same length. Most likely this
    will change the name of the function called. You can then write a C
    function with the same name to do something and then call the original. A
    small number of object program formats contain CRC or checksums which must
    be adjusted. There is some chance that the string may occur in other
    places. For example, changes of printf would also change fprintf and
    sprintf, unless those were specifically tested for.

    The program described can be standard C, assuming that it is possible to
    read and write object files as C binary files. I believe that is true in
    both Unix and windows files.

    -- glen

    -- glen
     
    Glen Herrmannsfeldt, Oct 9, 2003
    #9
  10. Keith Briggs

    Dan Pop Guest

    In <Cu1hb.246398$> "Glen Herrmannsfeldt" <> writes:


    >"Keith Briggs" <> wrote in message
    >news:bm1bsq$r7f$...
    >> Thank you for the suggestions, but I didn't make it clear in my original
    >> post that I do not have the source code. This needs to be done with an
    >> already compiled application.

    >
    >As others have said, at that point it isn't a C question anymore.
    >
    >Assuming, though, that you consider an object file as a C binary file, which
    >it may or may not be, depending on the implementation, then some things can
    >be done in C.
    >
    >I have before written programs that will recognize a given series of bytes
    >in a file and replace them with another set of bytes. (Assuming that the
    >system is byte oriented.) If you do that you can, for example, change
    >"puts" to "puty", or any other string of the same length. Most likely this
    >will change the name of the function called. You can then write a C
    >function with the same name to do something and then call the original. A
    >small number of object program formats contain CRC or checksums which must
    >be adjusted. There is some chance that the string may occur in other
    >places. For example, changes of printf would also change fprintf and
    >sprintf, unless those were specifically tested for.


    Without an intimate knowledge of the object file format, you can't
    perform such tests in a *reliable* fashion, i.e. a genuine printf may be
    preceded by a byte that happens to have the value of 'f'.

    Dan
    --
    Dan Pop
    DESY Zeuthen, RZ group
    Email:
     
    Dan Pop, Oct 9, 2003
    #10
    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. Honne Gowda A
    Replies:
    2
    Views:
    896
    Karl Heinz Buchegger
    Oct 31, 2003
  2. andy6
    Replies:
    2
    Views:
    773
    andy6 via DotNetMonster.com
    Jun 9, 2006
  3. Richard Tobin
    Replies:
    24
    Views:
    815
  4. Chris Rebert
    Replies:
    3
    Views:
    264
    MrJean1
    Dec 21, 2008
  5. Bob
    Replies:
    5
    Views:
    273
Loading...

Share This Page