Re: Wrapping routines

Arjen Markus wrote:
Hello,

My question requires a rather lengthy preparation:

I have been experimenting a bit with wrapping a library, that is,
I wanted to see if it is possible to place some other code between
the library routines and the calling program without actually changing
the source code of either.

For instance:

My program uses a routine sub_a. I want to see how sub_a is actually
called (with what parameters) and what the results are. But I do not
have the source code for it or I do not want to mess with it.

The strategy I follow is:

- routine sub_a is part of a module mod_a.
- I write a routine sub_b (part of a module mod_b) that calls sub_a.
- sub_b and sub_a have exactly the same interface, but sub_b prints
some extra information.
- I now have a third module - with the same name "mod_a" - that
renames
the routines in sub_b, thus hiding the fact that there is a
module mod_b.
- By storing all these modules in separate directories, (at least) the
compiler does not see any conflicts.

Schematically:

testwrap:
use mod_a (alternative module, gives access to mod_b)
|
+-> use mod_b (calls the original routines)
|
+-> mod_a (contains the original routines)

I have tried this on three different compilers (and associated
linkers,
g95, gfortran and CVF) and the result was what I hoped:

Wrapping sub_a ...
Original sub_a: x = 1
Original sub_ab: x = 1
Calling sub_ab:
Wrapping sub_ab ...
Original sub_ab: x = 1

So the original routines are nicely hidden from the original program
and the wrapping versions are called.

My question is:
Is this a mere coincidence? Or is this actually supposed to work this
way?

The reason I ask is that all compiler I know of prepend the internal
name of the routines with the name of the module. So I would have
thought there would be a conflict between the routines from the two
modules "mod_a", but there seems to be none.


Very clever technique. A linker not only keeps track of function names
but also the type of a name. In your case, there is no mod_a_sub_a
defined (normally marked 't') in mod_c.o, it's probably a stub
mod_b_sub_a ('U') in the ojbect file, do a 'nm' to see what's going on.
Also you can experiment by creating a real mod_a_sub_a in mod_c.o, in
which case I expect the linker to issue a name ambiguity error.

Fei
.

Relevant Pages

  • Re: AVR: Confused About an Array of Functon Pointers at Runtime
    ... It might be optimising the routines away. ... the linker or compiler may remove the code as being ... compiler / linker that the code is not dead code, ...
    (comp.arch.embedded)
  • Wrapping routines
    ... I have been experimenting a bit with wrapping a library, that is, ... the library routines and the calling program without actually changing ... have the source code for it or I do not want to mess with it. ... end subroutine sub_a ...
    (comp.lang.fortran)
  • managing header files
    ... while in the .h files the external declarations showed no arguments. ... Apparently that was the reason the compiler wasn't catching errors of the ... wrong number of arguments when routines were called from other files. ... Then I went through the all the header files ...
    (comp.lang.c.moderated)
  • Re: Sunperf library, pure functions?
    ... F95 compilers often were typically evolutionary ... > As such, if compiler internals included f90 in their names, these ... generic interface. ... question is a member of the 'family' of routines designated as ...
    (comp.lang.fortran)
  • Re: How to group objects from static library in a section?
    ... Using GNU linker ld, I'd like to create a section .rom_code ... ones such as math routines provided by libm.a. ... several utility routines (with all its dependencies) that will be used ... went to ROM, not its dependencies. ...
    (comp.lang.c)