This is under QNX 4.25, using Watcom 10.6.
To make a test framework I’m developing easier to use, I would really
like to be able to seamlessly insert wrappers around certain C library
functions. That is, if a user calls fopen() (for example), I would like
to be able to intercept that call with my own code, log the call, then
call the real fopen() function (the one in the C library).
I have replaced library functions in the past simply by defining my own
symbol of the same name and linking to it first. If I do that, however,
I’m not certain there is any way to later call the library function,
since the linker has now latched onto my local symbol.
A quick Google search didn’t turn up anything promising. Linux (and
presumably any system that uses the GNU toolchain, like QNX 6) supports
“weak symbols” to support this functionality. But is there any way of
accomplishing this under QNX 4? Thanks for any suggestions.
Josh Hamacher
FAAC Incorporated
Josh Hamacher <hamacher@faac.com> wrote:
This is under QNX 4.25, using Watcom 10.6.
To make a test framework I’m developing easier to use, I would really
like to be able to seamlessly insert wrappers around certain C library
functions. That is, if a user calls fopen() (for example), I would like
to be able to intercept that call with my own code, log the call, then
call the real fopen() function (the one in the C library).
I have replaced library functions in the past simply by defining my own
symbol of the same name and linking to it first. If I do that, however,
I’m not certain there is any way to later call the library function,
since the linker has now latched onto my local symbol.
A quick Google search didn’t turn up anything promising. Linux (and
presumably any system that uses the GNU toolchain, like QNX 6) supports
“weak symbols” to support this functionality. But is there any way of
accomplishing this under QNX 4? Thanks for any suggestions.
How about making up a intercept.h that defines functions like fopen()
and translates them to functions like my_fopen(). This would be done
by the C pre-processor. Write/define your functions my_fopen() in a
seperatre source file that is compiled without this include file.
This way, you can easily intercept or not intercept by including this
header or not including this header.
Caviot: This won’t intercept calls made from other library routines
that you don’t compile.
Alternative method (more work): make a copy of each library that
contains the standard library functions like fopen(). Patch their
names. I would use names that were very similar like FOPEN() and
make sure that this is incredibly well documented. Write you own
fopen() that calls FOPEN(). Adjust your makefiles to include the
appropriate libraries. Again, this way you can link against the
intercepted libraries or the non-intercepted libraries. This has the
advantage of intercepting calls from other library routines.
Good luck.
–
Bill Caroselli – Q-TPS Consulting
1-(626) 824-7983
qtps@earthlink.net
How about making up a intercept.h that defines functions like fopen()
and translates them to functions like my_fopen(). This would be done
by the C pre-processor. Write/define your functions my_fopen() in a
seperatre source file that is compiled without this include file.
This way, you can easily intercept or not intercept by including this
header or not including this header.
Caviot: This won’t intercept calls made from other library routines
that you don’t compile.
I’ve done this for some functions, but unfortunately our app uses a
bunch of precompiled libraries. I need to intercept the calls they
make, and I don’t think I could get permission to change all of them.
And I’m not sure I’d even want to - there are a bunch of them.
Alternative method (more work): make a copy of each library that
contains the standard library functions like fopen(). Patch their
names. I would use names that were very similar like FOPEN() and
make sure that this is incredibly well documented. Write you own
fopen() that calls FOPEN(). Adjust your makefiles to include the
appropriate libraries. Again, this way you can link against the
intercepted libraries or the non-intercepted libraries. This has the
advantage of intercepting calls from other library routines.
I really like the sound of this solution. I already have to link to
some custom libraries for the test framework, so what’s one more? I’ll
probably play around with this today. Thanks a lot.
Josh Hamacher
FAAC Incorporated