to exec a shared object

[Henry Thor Baldursson <henry at f-prot dot com>]

Hi.

This is a clueless letter, about a pretty dull subject, but I'm in over
my head and I was wondering if someone could throw me a paddle.

I am running gcc 3.2.2, and I'm wondering why shared objects that are
linked with -shared (binutils 2.13), aren't linked with libc, and don't
have an interpreter defined, still have some bogus entrypoint? And why
the ".init" code seems to try and call this bogus entrypoint also. The
entry points to the same address as the .text section.

Also, the entry never seems to be called, ld.so seems to totally ignore
it and just go buckwild and start running at 0x00000001. Even though the
entry is within a PT_LOAD segment, and inside a SHF_EXECINSTR section.
Attempts at setting a breakpoint in gdb results in an I/O error. And
running it ofcourse leads to a segfault.

I was thinking it was pretty ugly that when you execve a shared object
that it should segfault with EIP at 1, when we have a perfectly good
errno macro called ELIBEXEC, which is described as "Cannot exec a shared
library directly".

Ofcourse it's pretty futile to add a check like if (elf_ex.e_type ==
ET_DYN && !elf_ex.entry) return -ELIBEXEC; to Linux's binfmt_elf.c for
example, if the file actually has an entry point.

A look at the current entrypoint code from libm.so, 0x339c is .init, and
0x3480 is the entry: 
Disassembly of section .init:

0000339c <_init>:
    339c:       55                      push   %ebp
    339d:       89 e5                   mov    %esp,%ebp
    339f:       83 ec 08                sub    $0x8,%esp
    33a2:       e8 d9 00 00 00          call   3480 <call_gmon_start>
    33a7:       e8 60 01 00 00          call   350c <frame_dummy>
    33ac:       e8 57 77 01 00          call   1ab08 <__do_global_ctors_aux>
    33b1:       c9                      leave
    33b2:       c3                      ret

Disassembly of section .text:
 
00003480 <call_gmon_start>:
    3480:       55                      push   %ebp
    3481:       89 e5                   mov    %esp,%ebp
    3483:       53                      push   %ebx
    3484:       50                      push   %eax
    3485:       e8 00 00 00 00          call   348a <call_gmon_start+0xa>
    348a:       5b                      pop    %ebx
    348b:       81 c3 de e7 01 00       add    $0x1e7de,%ebx
    3491:       8b 83 4c 00 00 00       mov    0x4c(%ebx),%eax
    3497:       85 c0                   test   %eax,%eax
    3499:       74 02                   je     349d <call_gmon_start+0x1d>
    349b:       ff d0                   call   *%eax
    349d:       8b 5d fc                mov    0xfffffffc(%ebp),%ebx
    34a0:       c9                      leave
    34a1:       c3                      ret
    34a2:       90                      nop
    34a3:       90                      nop
Seems to be just some whack ass PIC code. Lord knows what is put in eax
from the GOT at 0x3491. Or why that address is never called.

Is it not possible to either have the entry defined as 0, or have entry
point to some code that doesn't require libc. Example for i386 would be
having this as an entry point:
asm volatile ("int $0x80\n" :: "a"(__NR_exit), "b"(ELIBEXEC));

If anyone could clue me in on this matter I'd be much obliged.

Henry.


-- 
Henrý Þór Baldursson
Software Developer
FRISK Software International

tel.: +354 540 7425
fax.: +354 540 7401

Attachment: signature.asc
Description: This is a digitally signed message part