trapping library calls

[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

[Richard Bos]

"Keith Briggs" <Ke**********@bt.com> 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

[Dan Pop]

In <bm**********@visp.bt.co.uk> "Keith Briggs" <Ke**********@bt.com> 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: Da*****@ifh.de

[Kris Wempa]

"Keith Briggs" <Ke**********@bt.com> wrote in message
news:bm**********@visp.bt.co.uk...

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.

[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

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message
news:3f****************@news.nl.net...

"Keith Briggs" <Ke**********@bt.com> 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]

"Keith Briggs" <Ke**********@bt.com> 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

[Artie Gold]

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.

[CBFalconer]

*** evil topposting fixed ***

Keith Briggs wrote:

"Richard Bos" <rl*@hoekstra-uitgeverij.nl> wrote in message

"Keith Briggs" <Ke**********@bt.com> 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 (cb********@yahoo.com) (cb********@worldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net> USE worldnet address!

[Glen Herrmannsfeldt]

"Keith Briggs" <Ke**********@bt.com> wrote in message
news:bm**********@visp.bt.co.uk...

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

[Dan Pop]

In <Cu********************@rwcrnsc51.ops.asp.att.ne t> "Glen Herrmannsfeldt" <ga*@ugcs.caltech.edu> writes:

"Keith Briggs" <Ke**********@bt.com> wrote in message
news:bm**********@visp.bt.co.uk...

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: Da*****@ifh.de