trapping library calls

K

Keith Briggs

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
 
R

Richard Bos

Keith Briggs said:
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
 
D

Dan Pop

In said:
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
 
K

Kris Wempa

Keith Briggs said:
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.
 
K

Keith Briggs

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
 
R

Richard Bos

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

Artie Gold

Keith said:
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
(or -- I'm guessing
here) and all shall be revealed!

HTH,
--ag
 
C

CBFalconer

*** evil topposting fixed ***

Keith said:
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.
 
G

Glen Herrmannsfeldt

Keith Briggs said:
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
 
D

Dan Pop

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
 

Ask a Question

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

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top