Shared Objects and Symbol Overrides

Shared Objects and Symbol Overrides

[Eric Todd]

How do you keep functions in a dynamically loaded library from making calls
to functions defined in the executable to which the library is being linked?

In particular, I'm having the following problem, and have checked every
source I can find (gcc man page, gcc docs, usenet, simple test program,
etc...) but can find no good solution. Any help would be greatly
appreciated.

I have an executable, say called 'program', which statically links a .o file
that defines a function f(). This version of f() prints a message that says
"program\n".

 I also have a dynamically linkable library called 'libA.so' which defines a
function f() and a function calls_f(). The function calls_f() unsurprisingly
calls the function f(), while the version of f() found in the library prints
a message reading "library\n". This library is not linked in any way (static
or dynamic) at compilation of 'program'.

In the main of 'program', I call dlopen to load libA.so, and then use dlsym
to get a pointer to calls_f(). I then execute the function pointer so
returned. Surprisingly, the result that I get is 'program'! It seems like
what's going on is that when dlopen causes relocation to occur, f() is bound
to the executable's version for both the executable and the library.

Is there any way I can keep this from happening? The desired behavior is for
the library's f() to be called when calls_f() (also in the library) is
called.

FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No, I'm
not using it on the .o files the executable is linking in.

Shared Objects and Symbol Overrides

[Eric Todd]

How do you keep functions in a dynamically loaded library from making calls
to functions defined in the executable to which the library is being linked?

In particular, I'm having the following problem, and have checked every
source I can find (gcc man page, gcc docs, usenet, simple test program,
etc...) but can find no good solution. Any help would be greatly
appreciated.

I have an executable, say called 'program', which statically links a .o file
that defines a function f(). This version of f() prints a message that says
"program\n".

 I also have a dynamically linkable library called 'libA.so' which defines a
function f() and a function calls_f(). The function calls_f() unsurprisingly
calls the function f(), while the version of f() found in the library prints
a message reading "library\n". This library is not linked in any way (static
or dynamic) at compilation of 'program'.

In the main of 'program', I call dlopen to load libA.so, and then use dlsym
to get a pointer to calls_f(). I then execute the function pointer so
returned. Surprisingly, the result that I get is 'program'! It seems like
what's going on is that when dlopen causes relocation to occur, f() is bound
to the executable's version for both the executable and the library.

Is there any way I can keep this from happening? The desired behavior is for
the library's f() to be called when calls_f() (also in the library) is
called.

FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No, I'm
not using it on the .o files the executable is linking in.

Shared Objects and Symbol Overrides

[Eric Todd]

How do you keep functions in a dynamically loaded library from making calls
to functions defined in the executable to which the library is being linked?

In particular, I'm having the following problem, and have checked every
source I can find (gcc man page, gcc docs, usenet, simple test program,
etc...) but can find no good solution. Any help would be greatly
appreciated.

I have an executable, say called 'program', which statically links a .o file
that defines a function f(). This version of f() prints a message that says
"program\n".

 I also have a dynamically linkable library called 'libA.so' which defines a
function f() and a function calls_f(). The function calls_f() unsurprisingly
calls the function f(), while the version of f() found in the library prints
a message reading "library\n". This library is not linked in any way (static
or dynamic) at compilation of 'program'.

In the main of 'program', I call dlopen to load libA.so, and then use dlsym
to get a pointer to calls_f(). I then execute the function pointer so
returned. Surprisingly, the result that I get is 'program'! It seems like
what's going on is that when dlopen causes relocation to occur, f() is bound
to the executable's version for both the executable and the library.

Is there any way I can keep this from happening? The desired behavior is for
the library's f() to be called when calls_f() (also in the library) is
called.

FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No, I'm
not using it on the .o files the executable is linking in.

Re: Shared Objects and Symbol Overrides

[Arthur Gold]

Eric:

Show us (or me) your test code.

Your approach _does_ seem correct (I suspect this may be one of those
"another set of eyes" kinda things).

HTH,
--ag

BTW - In research I've been doing we're using overrides/preloaded
libraries quite extensively, so I've probably made most, if not all, of
the "slap yourself in the forehead" kind of errors ;-0 !!!!


Eric Todd wrote:
> 
> How do you keep functions in a dynamically loaded library from making calls
> to functions defined in the executable to which the library is being linked?
> 
> In particular, I'm having the following problem, and have checked every
> source I can find (gcc man page, gcc docs, usenet, simple test program,
> etc...) but can find no good solution. Any help would be greatly
> appreciated.
> 
> I have an executable, say called 'program', which statically links a .o file
> that defines a function f(). This version of f() prints a message that says
> "program\n".
> 
>  I also have a dynamically linkable library called 'libA.so' which defines a
> function f() and a function calls_f(). The function calls_f() unsurprisingly
> calls the function f(), while the version of f() found in the library prints
> a message reading "library\n". This library is not linked in any way (static
> or dynamic) at compilation of 'program'.
> 
> In the main of 'program', I call dlopen to load libA.so, and then use dlsym
> to get a pointer to calls_f(). I then execute the function pointer so
> returned. Surprisingly, the result that I get is 'program'! It seems like
> what's going on is that when dlopen causes relocation to occur, f() is bound
> to the executable's version for both the executable and the library.
> 
> Is there any way I can keep this from happening? The desired behavior is for
> the library's f() to be called when calls_f() (also in the library) is
> called.
> 
> FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No, I'm
> not using it on the .o files the executable is linking in.

-- 
Artie Gold, Austin, TX
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"

Re: Shared Objects and Symbol Overrides

[Eric Todd]

Arthur,

Below is sample code that illustrates the problem.

For those who are joining late in the game, the puzzle is to convince the
function calls_f(), which is extracted from a library which is manually
loaded at runtime, to use the version of f() found in the library, instead
of the version found in the orignal executable. I.e. The program execution
should be:

>prog
Library
Program

Thanks!
Eric

p.s. I'm using Solaris 2.7 and gcc 2.95.1

---- program.cpp -----
#include <stdio.h>
#include <stream.h>
#include <dlfcn.h>

extern "C"
void f() {
    cout << "Program" << endl;
}

main () {
   void *mHandle;
   void (*fptr)(void);

   mHandle = dlopen("./libLibrary.so", RTLD_NOW);
   if (! mHandle ) {
      char * temp;
      temp = dlerror();
      cout << temp << endl;
   }

   fptr = (void (*)(void))dlsym (mHandle, "calls_f");
   if (!fptr) {
      cout << "Error!" << endl;
   }
   else {
      (*fptr)();
   }
   f();
}
---- end program.cpp ----

---- library.cpp ----
#include <stdio.h>

extern "C"
void f() {
   printf ("Library\n");
}

extern "C"
void calls_f() {
   f();
}
---- end library.cpp ----

---- to build test program ----
g++ -g -c program.cpp  -o program.o
g++ -o prog -ldl program.o
g++ -fPIC -g -c library.cpp -o library.o
g++ -shared -o libLibrary.so  library.o
---- end build ----

---- when prog is run ----
> prog
Program
Program
>
---- end program execution ----
Arthur Gold <agold@bga.com> wrote in message
news: 37F547EE.A5924FB7@bga.com ...
> Eric:
>
> Show us (or me) your test code.
>
> Your approach _does_ seem correct (I suspect this may be one of those
> "another set of eyes" kinda things).
>
> HTH,
> --ag
>
> BTW - In research I've been doing we're using overrides/preloaded
> libraries quite extensively, so I've probably made most, if not all, of
> the "slap yourself in the forehead" kind of errors ;-0 !!!!
>
>
> Eric Todd wrote:
> >
> > How do you keep functions in a dynamically loaded library from making
calls
> > to functions defined in the executable to which the library is being
linked?
> >
> > In particular, I'm having the following problem, and have checked every
> > source I can find (gcc man page, gcc docs, usenet, simple test program,
> > etc...) but can find no good solution. Any help would be greatly
> > appreciated.
> >
> > I have an executable, say called 'program', which statically links a .o
file
> > that defines a function f(). This version of f() prints a message that
says
> > "program\n".
> >
> >  I also have a dynamically linkable library called 'libA.so' which
defines a
> > function f() and a function calls_f(). The function calls_f()
unsurprisingly
> > calls the function f(), while the version of f() found in the library
prints
> > a message reading "library\n". This library is not linked in any way
(static
> > or dynamic) at compilation of 'program'.
> >
> > In the main of 'program', I call dlopen to load libA.so, and then use
dlsym
> > to get a pointer to calls_f(). I then execute the function pointer so
> > returned. Surprisingly, the result that I get is 'program'! It seems
like
> > what's going on is that when dlopen causes relocation to occur, f() is
bound
> > to the executable's version for both the executable and the library.
> >
> > Is there any way I can keep this from happening? The desired behavior is
for
> > the library's f() to be called when calls_f() (also in the library) is
> > called.
> >
> > FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No,
I'm
> > not using it on the .o files the executable is linking in.
>
> --
> Artie Gold, Austin, TX
> mailto:agold@bga.com or mailto:agold@cs.utexas.edu
> --
> Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"

Re: Shared Objects and Symbol Overrides

[Eric Todd]

For future reference, the solution to the problem described below is to
use -symbolic
when compiling the library, instead of -shared.  Thus, in the example, the
compile line would read:

g++ -symbolic -o libLibrary.so  library.o

This gives the desired results because all global symbols within the library
are bound at compile time, when using the -symbolic option.

Regards,

Eric

Eric Todd <etodd@maxis.com> wrote in message
news: 3i5K3.27$4M5.1510@nuq-read.news.verio.net ...
> Arthur,
>
> Below is sample code that illustrates the problem.
>
> For those who are joining late in the game, the puzzle is to convince the
> function calls_f(), which is extracted from a library which is manually
> loaded at runtime, to use the version of f() found in the library, instead
> of the version found in the orignal executable. I.e. The program execution
> should be:
>
> >prog
> Library
> Program
>
> Thanks!
> Eric
>
> p.s. I'm using Solaris 2.7 and gcc 2.95.1
>
> ---- program.cpp -----
> #include <stdio.h>
> #include <stream.h>
> #include <dlfcn.h>
>
> extern "C"
> void f() {
>     cout << "Program" << endl;
> }
>
> main () {
>    void *mHandle;
>    void (*fptr)(void);
>
>    mHandle = dlopen("./libLibrary.so", RTLD_NOW);
>    if (! mHandle ) {
>       char * temp;
>       temp = dlerror();
>       cout << temp << endl;
>    }
>
>    fptr = (void (*)(void))dlsym (mHandle, "calls_f");
>    if (!fptr) {
>       cout << "Error!" << endl;
>    }
>    else {
>       (*fptr)();
>    }
>    f();
> }
> ---- end program.cpp ----
>
> ---- library.cpp ----
> #include <stdio.h>
>
> extern "C"
> void f() {
>    printf ("Library\n");
> }
>
> extern "C"
> void calls_f() {
>    f();
> }
> ---- end library.cpp ----
>
> ---- to build test program ----
> g++ -g -c program.cpp  -o program.o
> g++ -o prog -ldl program.o
> g++ -fPIC -g -c library.cpp -o library.o
> g++ -shared -o libLibrary.so  library.o
> ---- end build ----
>
> ---- when prog is run ----
> > prog
> Program
> Program
> >
> ---- end program execution ----
> Arthur Gold <agold@bga.com> wrote in message
> news: 37F547EE.A5924FB7@bga.com ...
> > Eric:
> >
> > Show us (or me) your test code.
> >
> > Your approach _does_ seem correct (I suspect this may be one of those
> > "another set of eyes" kinda things).
> >
> > HTH,
> > --ag
> >
> > BTW - In research I've been doing we're using overrides/preloaded
> > libraries quite extensively, so I've probably made most, if not all, of
> > the "slap yourself in the forehead" kind of errors ;-0 !!!!
> >
> >
> > Eric Todd wrote:
> > >
> > > How do you keep functions in a dynamically loaded library from making
> calls
> > > to functions defined in the executable to which the library is being
> linked?
> > >
> > > In particular, I'm having the following problem, and have checked
every
> > > source I can find (gcc man page, gcc docs, usenet, simple test
program,
> > > etc...) but can find no good solution. Any help would be greatly
> > > appreciated.
> > >
> > > I have an executable, say called 'program', which statically links a
.o
> file
> > > that defines a function f(). This version of f() prints a message that
> says
> > > "program\n".
> > >
> > >  I also have a dynamically linkable library called 'libA.so' which
> defines a
> > > function f() and a function calls_f(). The function calls_f()
> unsurprisingly
> > > calls the function f(), while the version of f() found in the library
> prints
> > > a message reading "library\n". This library is not linked in any way
> (static
> > > or dynamic) at compilation of 'program'.
> > >
> > > In the main of 'program', I call dlopen to load libA.so, and then use
> dlsym
> > > to get a pointer to calls_f(). I then execute the function pointer so
> > > returned. Surprisingly, the result that I get is 'program'! It seems
> like
> > > what's going on is that when dlopen causes relocation to occur, f() is
> bound
> > > to the executable's version for both the executable and the library.
> > >
> > > Is there any way I can keep this from happening? The desired behavior
is
> for
> > > the library's f() to be called when calls_f() (also in the library) is
> > > called.
> > >
> > > FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No,
> I'm
> > > not using it on the .o files the executable is linking in.
> >
> > --
> > Artie Gold, Austin, TX
> > mailto:agold@bga.com or mailto:agold@cs.utexas.edu
> > --
> > Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"
>
>

Re: Shared Objects and Symbol Overrides

[Eric Todd]

For future reference, the solution to the problem described below is to
use -symbolic
when compiling the library, instead of -shared.  Thus, in the example, the
compile line would read:

g++ -symbolic -o libLibrary.so  library.o

This gives the desired results because all global symbols within the library
are bound at compile time, when using the -symbolic option.

Regards,

Eric

Eric Todd <etodd@maxis.com> wrote in message
news: 3i5K3.27$4M5.1510@nuq-read.news.verio.net ...
> Arthur,
>
> Below is sample code that illustrates the problem.
>
> For those who are joining late in the game, the puzzle is to convince the
> function calls_f(), which is extracted from a library which is manually
> loaded at runtime, to use the version of f() found in the library, instead
> of the version found in the orignal executable. I.e. The program execution
> should be:
>
> >prog
> Library
> Program
>
> Thanks!
> Eric
>
> p.s. I'm using Solaris 2.7 and gcc 2.95.1
>
> ---- program.cpp -----
> #include <stdio.h>
> #include <stream.h>
> #include <dlfcn.h>
>
> extern "C"
> void f() {
>     cout << "Program" << endl;
> }
>
> main () {
>    void *mHandle;
>    void (*fptr)(void);
>
>    mHandle = dlopen("./libLibrary.so", RTLD_NOW);
>    if (! mHandle ) {
>       char * temp;
>       temp = dlerror();
>       cout << temp << endl;
>    }
>
>    fptr = (void (*)(void))dlsym (mHandle, "calls_f");
>    if (!fptr) {
>       cout << "Error!" << endl;
>    }
>    else {
>       (*fptr)();
>    }
>    f();
> }
> ---- end program.cpp ----
>
> ---- library.cpp ----
> #include <stdio.h>
>
> extern "C"
> void f() {
>    printf ("Library\n");
> }
>
> extern "C"
> void calls_f() {
>    f();
> }
> ---- end library.cpp ----
>
> ---- to build test program ----
> g++ -g -c program.cpp  -o program.o
> g++ -o prog -ldl program.o
> g++ -fPIC -g -c library.cpp -o library.o
> g++ -shared -o libLibrary.so  library.o
> ---- end build ----
>
> ---- when prog is run ----
> > prog
> Program
> Program
> >
> ---- end program execution ----
> Arthur Gold <agold@bga.com> wrote in message
> news: 37F547EE.A5924FB7@bga.com ...
> > Eric:
> >
> > Show us (or me) your test code.
> >
> > Your approach _does_ seem correct (I suspect this may be one of those
> > "another set of eyes" kinda things).
> >
> > HTH,
> > --ag
> >
> > BTW - In research I've been doing we're using overrides/preloaded
> > libraries quite extensively, so I've probably made most, if not all, of
> > the "slap yourself in the forehead" kind of errors ;-0 !!!!
> >
> >
> > Eric Todd wrote:
> > >
> > > How do you keep functions in a dynamically loaded library from making
> calls
> > > to functions defined in the executable to which the library is being
> linked?
> > >
> > > In particular, I'm having the following problem, and have checked
every
> > > source I can find (gcc man page, gcc docs, usenet, simple test
program,
> > > etc...) but can find no good solution. Any help would be greatly
> > > appreciated.
> > >
> > > I have an executable, say called 'program', which statically links a
.o
> file
> > > that defines a function f(). This version of f() prints a message that
> says
> > > "program\n".
> > >
> > >  I also have a dynamically linkable library called 'libA.so' which
> defines a
> > > function f() and a function calls_f(). The function calls_f()
> unsurprisingly
> > > calls the function f(), while the version of f() found in the library
> prints
> > > a message reading "library\n". This library is not linked in any way
> (static
> > > or dynamic) at compilation of 'program'.
> > >
> > > In the main of 'program', I call dlopen to load libA.so, and then use
> dlsym
> > > to get a pointer to calls_f(). I then execute the function pointer so
> > > returned. Surprisingly, the result that I get is 'program'! It seems
> like
> > > what's going on is that when dlopen causes relocation to occur, f() is
> bound
> > > to the executable's version for both the executable and the library.
> > >
> > > Is there any way I can keep this from happening? The desired behavior
is
> for
> > > the library's f() to be called when calls_f() (also in the library) is
> > > called.
> > >
> > > FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No,
> I'm
> > > not using it on the .o files the executable is linking in.
> >
> > --
> > Artie Gold, Austin, TX
> > mailto:agold@bga.com or mailto:agold@cs.utexas.edu
> > --
> > Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"
>
>

Re: Shared Objects and Symbol Overrides

[Arthur Gold]

Eric:

Show us (or me) your test code.

Your approach _does_ seem correct (I suspect this may be one of those
"another set of eyes" kinda things).

HTH,
--ag

BTW - In research I've been doing we're using overrides/preloaded
libraries quite extensively, so I've probably made most, if not all, of
the "slap yourself in the forehead" kind of errors ;-0 !!!!


Eric Todd wrote:
> 
> How do you keep functions in a dynamically loaded library from making calls
> to functions defined in the executable to which the library is being linked?
> 
> In particular, I'm having the following problem, and have checked every
> source I can find (gcc man page, gcc docs, usenet, simple test program,
> etc...) but can find no good solution. Any help would be greatly
> appreciated.
> 
> I have an executable, say called 'program', which statically links a .o file
> that defines a function f(). This version of f() prints a message that says
> "program\n".
> 
>  I also have a dynamically linkable library called 'libA.so' which defines a
> function f() and a function calls_f(). The function calls_f() unsurprisingly
> calls the function f(), while the version of f() found in the library prints
> a message reading "library\n". This library is not linked in any way (static
> or dynamic) at compilation of 'program'.
> 
> In the main of 'program', I call dlopen to load libA.so, and then use dlsym
> to get a pointer to calls_f(). I then execute the function pointer so
> returned. Surprisingly, the result that I get is 'program'! It seems like
> what's going on is that when dlopen causes relocation to occur, f() is bound
> to the executable's version for both the executable and the library.
> 
> Is there any way I can keep this from happening? The desired behavior is for
> the library's f() to be called when calls_f() (also in the library) is
> called.
> 
> FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No, I'm
> not using it on the .o files the executable is linking in.

-- 
Artie Gold, Austin, TX
mailto:agold@bga.com or mailto:agold@cs.utexas.edu
--
Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"

Re: Shared Objects and Symbol Overrides

[Eric Todd]

Arthur,

Below is sample code that illustrates the problem.

For those who are joining late in the game, the puzzle is to convince the
function calls_f(), which is extracted from a library which is manually
loaded at runtime, to use the version of f() found in the library, instead
of the version found in the orignal executable. I.e. The program execution
should be:

>prog
Library
Program

Thanks!
Eric

p.s. I'm using Solaris 2.7 and gcc 2.95.1

---- program.cpp -----
#include <stdio.h>
#include <stream.h>
#include <dlfcn.h>

extern "C"
void f() {
    cout << "Program" << endl;
}

main () {
   void *mHandle;
   void (*fptr)(void);

   mHandle = dlopen("./libLibrary.so", RTLD_NOW);
   if (! mHandle ) {
      char * temp;
      temp = dlerror();
      cout << temp << endl;
   }

   fptr = (void (*)(void))dlsym (mHandle, "calls_f");
   if (!fptr) {
      cout << "Error!" << endl;
   }
   else {
      (*fptr)();
   }
   f();
}
---- end program.cpp ----

---- library.cpp ----
#include <stdio.h>

extern "C"
void f() {
   printf ("Library\n");
}

extern "C"
void calls_f() {
   f();
}
---- end library.cpp ----

---- to build test program ----
g++ -g -c program.cpp  -o program.o
g++ -o prog -ldl program.o
g++ -fPIC -g -c library.cpp -o library.o
g++ -shared -o libLibrary.so  library.o
---- end build ----

---- when prog is run ----
> prog
Program
Program
>
---- end program execution ----
Arthur Gold <agold@bga.com> wrote in message
news: 37F547EE.A5924FB7@bga.com ...
> Eric:
>
> Show us (or me) your test code.
>
> Your approach _does_ seem correct (I suspect this may be one of those
> "another set of eyes" kinda things).
>
> HTH,
> --ag
>
> BTW - In research I've been doing we're using overrides/preloaded
> libraries quite extensively, so I've probably made most, if not all, of
> the "slap yourself in the forehead" kind of errors ;-0 !!!!
>
>
> Eric Todd wrote:
> >
> > How do you keep functions in a dynamically loaded library from making
calls
> > to functions defined in the executable to which the library is being
linked?
> >
> > In particular, I'm having the following problem, and have checked every
> > source I can find (gcc man page, gcc docs, usenet, simple test program,
> > etc...) but can find no good solution. Any help would be greatly
> > appreciated.
> >
> > I have an executable, say called 'program', which statically links a .o
file
> > that defines a function f(). This version of f() prints a message that
says
> > "program\n".
> >
> >  I also have a dynamically linkable library called 'libA.so' which
defines a
> > function f() and a function calls_f(). The function calls_f()
unsurprisingly
> > calls the function f(), while the version of f() found in the library
prints
> > a message reading "library\n". This library is not linked in any way
(static
> > or dynamic) at compilation of 'program'.
> >
> > In the main of 'program', I call dlopen to load libA.so, and then use
dlsym
> > to get a pointer to calls_f(). I then execute the function pointer so
> > returned. Surprisingly, the result that I get is 'program'! It seems
like
> > what's going on is that when dlopen causes relocation to occur, f() is
bound
> > to the executable's version for both the executable and the library.
> >
> > Is there any way I can keep this from happening? The desired behavior is
for
> > the library's f() to be called when calls_f() (also in the library) is
> > called.
> >
> > FYI, I'm using Solaris 2.7 and GCC 2.95.1. Yes,, I'm using -fPIC. No,
I'm
> > not using it on the .o files the executable is linking in.
>
> --
> Artie Gold, Austin, TX
> mailto:agold@bga.com or mailto:agold@cs.utexas.edu
> --
> Pet peeve: "its" = belonging or pertaining to "it" | "it's" = "it is"