Specifying an entry point for shared objects

Specifying an entry point for shared objects

Post by tarse » Tue, 15 Oct 2002 23:03:05



How is it possible to specify an entry point for shared objects so that
they can be executed. For example, consider the following code:

#include <unistd.h>

void
foo (void)
{
  write(STDOUT_FILENO, "foo\n", 4);
  _exit(0);

Quote:}

Now if I want to compile this and link it into a shared object which can
be executed, these are apparently the steps to follow:

# gcc -g -fPIC -o foo.o foo.c
# gcc -shared -e foo -o libfoo.so foo.o
# ./libfoo.so
Segmentation fault

What's odd is that running libfoo.so in gdb and setting a breakpoint to
foo does indeed break. But then, the first single step segfaults. Not
having much else to debug this problem, I'd really like to know how to do
this.

TIA

 
 
 

Specifying an entry point for shared objects

Post by Martin Dicko » Wed, 16 Oct 2002 00:49:26



> How is it possible to specify an entry point for shared objects so that
> they can be executed. For example, consider the following code:

> #include <unistd.h>

> void
> foo (void)
> {
>  write(STDOUT_FILENO, "foo\n", 4);
>  _exit(0);
> }

> Now if I want to compile this and link it into a shared object which can
> be executed, these are apparently the steps to follow:

> # gcc -g -fPIC -o foo.o foo.c
> # gcc -shared -e foo -o libfoo.so foo.o
> # ./libfoo.so
> Segmentation fault

> What's odd is that running libfoo.so in gdb and setting a breakpoint to
> foo does indeed break. But then, the first single step segfaults. Not
> having much else to debug this problem, I'd really like to know how to do
> this.

You have to do all the stuff that is usually (ie, in executables) done
by the startup code yourself. This might include code relocation, proper
invocation of the run-time linker, and symbol resolution.

Martin

 
 
 

Specifying an entry point for shared objects

Post by Fletcher Glen » Wed, 16 Oct 2002 01:02:32



> How is it possible to specify an entry point for shared objects so that
> they can be executed. For example, consider the following code:

> #include <unistd.h>

> void
> foo (void)
> {
>   write(STDOUT_FILENO, "foo\n", 4);
>   _exit(0);
> }

> Now if I want to compile this and link it into a shared object which can
> be executed, these are apparently the steps to follow:

> # gcc -g -fPIC -o foo.o foo.c
> # gcc -shared -e foo -o libfoo.so foo.o
> # ./libfoo.so
> Segmentation fault

> What's odd is that running libfoo.so in gdb and setting a breakpoint to
> foo does indeed break. But then, the first single step segfaults. Not
> having much else to debug this problem, I'd really like to know how to do
> this.

> TIA

Anything you execute from the command line must have
a main().  Your attempt to run without a main() will
rightfully fail because the system does not have an
address for main() and it will segfault attempting to
use some garbage address.  OTOH, no shared object should
have a main as this would conflict with anything that
tried to do a runtime load.

If you want to execute foo from a shared object, simply
build a program that links to libfoo.so.

--
                Fletcher Glenn

 
 
 

Specifying an entry point for shared objects

Post by Marc Tardi » Wed, 16 Oct 2002 02:09:33




> > How is it possible to specify an entry point for shared objects so that
> > they can be executed. For example, consider the following code:

> > #include <unistd.h>

> > void
> > foo (void)
> > {
> >   write(STDOUT_FILENO, "foo\n", 4);
> >   _exit(0);
> > }

> > Now if I want to compile this and link it into a shared object which can
> > be executed, these are apparently the steps to follow:

> > # gcc -g -fPIC -o foo.o foo.c
> > # gcc -shared -e foo -o libfoo.so foo.o
> > # ./libfoo.so
> > Segmentation fault

> > What's odd is that running libfoo.so in gdb and setting a breakpoint to
> > foo does indeed break. But then, the first single step segfaults. Not
> > having much else to debug this problem, I'd really like to know how to do
> > this.

> > TIA

> Anything you execute from the command line must have
> a main().  Your attempt to run without a main() will
> rightfully fail because the system does not have an
> address for main() and it will segfault attempting to
> use some garbage address.  OTOH, no shared object should
> have a main as this would conflict with anything that
> tried to do a runtime load.

> If you want to execute foo from a shared object, simply
> build a program that links to libfoo.so.

And yet, it is possible to execute /lib/libc.so.6 on Linux. I looked at
the symbol table of this shared object and found no trace of main.

When reading the ld manpage, the -e option is said to specify the symbol
for beginning execution of the program. In the original example, if foo
is the entry point, shouldn't it be executed regardless of the fact it's
a shared object?

Marc - Sitepak

 
 
 

Specifying an entry point for shared objects

Post by Martin Dicko » Wed, 16 Oct 2002 02:48:22




>> Anything you execute from the command line must have
>> a main().  Your attempt to run without a main() will
>> rightfully fail because the system does not have an
>> address for main() and it will segfault attempting to
>> use some garbage address.  OTOH, no shared object should
>> have a main as this would conflict with anything that
>> tried to do a runtime load.

>> If you want to execute foo from a shared object, simply
>> build a program that links to libfoo.so.

> And yet, it is possible to execute /lib/libc.so.6 on Linux.

Yes. It uses the -e linker option to set the entry point.

Quote:> I looked at the symbol table of this shared object and found no
> trace of main.

Executables are usually set up in such a way that the startup code
executes first. The startup code then invokes the runtime linker
(/lib/ld-linux.so.2 on GNU/Linux systems) to load shared libraries,
resolves symbols, and finally calls "main". But there is no require-
ment to link to startup code which does exactly this -- in fact, the
GNU C Library has some code which instead just prints a copyright
notice and then terminates. Of course, it doesn't have to care about
loading the C library to do the printing, because it *is* the C
library. :)

Quote:> When reading the ld manpage, the -e option is said to specify the
> symbol for beginning execution of the program. In the original
> example, if foo is the entry point, shouldn't it be executed
> regardless of the fact it's a shared object?

It is. The problem is that it cannot call the "write" or "_exit"
functions without first loading the C library and locating the
implementations of these functions.

Martin

 
 
 

Specifying an entry point for shared objects

Post by Paul Pluzhniko » Wed, 16 Oct 2002 16:04:04



> Executables are usually set up in such a way that the startup code
> executes first.

True, for some definition of "first".

Quote:> The startup code then invokes the runtime linker
> (/lib/ld-linux.so.2 on GNU/Linux systems) to load shared libraries,
> resolves symbols,

False. The runtime loader is not called by the start-up code.
Rather, it is called by the kernel itself, immediately after execve,
and *before* the executable entry point.

In fact, it is the loader that calls executable entry point, after
mapping all the DT_NEEDed shared libraries (and doing a whole bunch
of other stuff). Which is why this command:

  env LD_TRACE_LOADED_OBJECTS=1 /bin/date

does not actually print the date at all (and never executes
code from /bin/date).

Quote:> and finally calls "main".

True.

Cheers,
--
In order to understand recursion you must first understand recursion.

 
 
 

1. Shared Objects entry point

Hi Again,
  Another stupid question from a Win32 programmer.  I am writing a
shared object (.so) file, in Windows this is a DLL.  In a Windows DLL
there is an entry point (DLLMain or DLLEntryPoint) which is called when
the DLL is loaded and unloaded, so you can perform initialization and
cleanup of stuff.  Does Unix (specifically Solaris) have the same
concept?  If so what is the function and what is its prototype?

Agains thanks in advance

Sent via Deja.com http://www.deja.com/
Before you buy.

2. Infomations about changing the kernel parameter

3. creating new shared object from existing shared objects ??

4. Backplane IP Pseudo-Adapter

5. what do entry points of object files mean?

6. How to change password for hole network?

7. shared library entry point

8. XDMCP client How?

9. Shared libraries - entry/exit points

10. Problem: shared object loading runs constructor of a static object, but static linkage does not.

11. tunnel point to point vs physical point to point

12. error in loading shared libraries: libXmu.so.6: cannot open shared object

13. semaphors & memory share & object share