ldd misreports some apps as not dynamic

[Jeff Bailey]

The symptom is that executables produced on my system show up as:

jbailey@hurd:~/test$ ldd main
        not a dynamic executable

However, a few things suggest that it really is:

jbailey@hurd:~/test$ file main
main: ELF 32-bit LSB executable, Intel 80386, version 1, dynamically linked 
(uses shared libs), stripped
jbailey@hurd:~/test$ LD_TRACE_LOADED_OBJECTS=1 ./main
        libc.so.0.2 => /lib/libc.so.0.2 (0x0102c000)
        /lib/ld.so => /lib/ld.so (0x00001000)
        libmachuser.so.1 => /lib/libmachuser.so.1 (0x0118f000)
        libhurduser.so.0.0 => /lib/libhurduser.so.0.0 (0x011a0000)
jbailey@hurd:~/test$ ls -l main
-rwxr-xr-x    1 jbailey  jbailey      4646 Oct 16 17:34 main

I discovered that mutt on my system reports correctly, so I loaded the 
libc0.2-dbg package, and did the following in two seperate windows:

gdb /lib/debian/ld-2.2.4.so
(...)
set args --verify ./mutt

(and same for ./main)

I tried to take down what was happening whenever I thought it would be
useful.  If there's more data or better data that you need, let me
know.  In all of these cases, "./mutt" (the working one) is on top.
"./main" (the non-working one) is on the bottom.

I noticed that fbp weren't at the same address.  Alot of pointers were
off by that number of bytes.  I also did a print *fbp, And after the
first line of characters, they didn't stay the same.  However, I
didn't know what to do with what I was looking at. =) It looked alot
like the beggining of the app, but I'm not sure what part to include
here.

_dl_map_object_from_fd (name=0x1026020 "./mutt", fd=42, fbp=0x1025630, 
    realname=0x102b2b0 "./mutt", loader=0x0, l_type=1, mode=0) at dl-load.c:762

_dl_map_object_from_fd (name=0x1026020 "./main", fd=42, fbp=0x1025640, 
    realname=0x102b2b0 "./main", loader=0x0, l_type=1, mode=0) at dl-load.c:762

(...)

833       l = _dl_new_object (realname, name, l_type, loader);

(top)
_dl_new_object (realname=0x0, libname=0x0, type=0, loader=0x0)
    at dl-object.c:36
36      {

(bottom)
_dl_new_object (realname=0xffffffff <Address 0xffffffff out of bounds>, 
    libname=0x0, type=342347, loader=0x0) at dl-object.c:36
36      {

(Resolved later...)

53        new->l_name = realname;
(gdb) print realname
$17 = 0x102b2b0 "./mutt"

53        new->l_name = realname;
(gdb) print realname
$14 = 0x102b2b0 "./main"

All basically the same until:
771           caddr_t mapat = __mmap ((caddr_t) mapstart, len, prot,
(gdb) next
774           if (mapat == MAP_FAILED)
(gdb) step
983             if (l->l_phdr == 0
(gdb) 

771           caddr_t mapat = __mmap ((caddr_t) mapstart, len, prot,
(gdb) next
774           if (mapat == MAP_FAILED)
(gdb) step
775             LOSE (errno, N_("failed to map segment from shared object"));
(gdb) 

(...)  I stopped at this point to take a backtrace.

#0  _dl_map_object_from_fd (name=0x1026020 "./mutt", fd=42, fbp=0x1025630, 
    realname=0x102b2b0 "./mutt", loader=0x0, l_type=1, mode=0)
    at dl-load.c:1033
#1  0x00008b34 in _dl_map_object (loader=0x0, name=0x1026020 "./mutt", 
    preloaded=0, type=1, trace_mode=0, mode=0) at dl-load.c:1748
#2  0x00003feb in map_doit (a=0x1025bc0) at rtld.c:309
#3  0x0000c692 in _dl_catch_error (objname=0x1025bc8, errstring=0x1025bcc, 
    operate=0x3fc0 <map_doit>, args=0x1025bc0) at dl-error.c:152
#4  0x00004354 in dl_main (phdr=0x0, phnum=0, user_entry=0x1025cb0)
    at rtld.c:498
#5  0x0000e93e in go (argdata=0x1025c1c)
    at ../sysdeps/mach/hurd/dl-sysdep.c:182
#6  0x00010622 in _hurd_startup (argptr=0x1026000, main=0x1025d70)
    at hurdstartup.c:189
#7  0x0000ea69 in _dl_sysdep_start (start_argptr=0x1026000, 
    dl_main=0x40b4 <dl_main>) at ../sysdeps/mach/hurd/dl-sysdep.c:246
#8  0x00003f6a in _dl_start_final (arg=0x1026000, bootstrap_map_p=0x1025e50, 
    start_time=0) at rtld.c:249
#9  0x00003edb in _dl_start (arg=0x1026000) at rtld.c:201
(gdb) 

(gdb) bt
#0  _dl_map_object_from_fd (name=0x1026020 "./main", fd=42, fbp=0x1025640, 
    realname=0x102b2b0 "./main", loader=0x0, l_type=1, mode=0) at dl-load.c:775
#1  0x00008b34 in _dl_map_object (loader=0x0, name=0x1026020 "./main", 
    preloaded=0, type=1, trace_mode=0, mode=0) at dl-load.c:1748
#2  0x00003feb in map_doit (a=0x1025bd0) at rtld.c:309
#3  0x0000c692 in _dl_catch_error (objname=0x1025bd8, errstring=0x1025bdc, 
    operate=0x3fc0 <map_doit>, args=0x1025bd0) at dl-error.c:152
#4  0x00004354 in dl_main (phdr=0x0, phnum=0, user_entry=0x1025cb8)
    at rtld.c:498
#5  0x0000e93e in go (argdata=0x1025c2c)
    at ../sysdeps/mach/hurd/dl-sysdep.c:182
#6  0x00010622 in _hurd_startup (argptr=0x1026000, main=0x1025d70)
    at hurdstartup.c:189
#7  0x0000ea69 in _dl_sysdep_start (start_argptr=0x1026000, 
    dl_main=0x40b4 <dl_main>) at ../sysdeps/mach/hurd/dl-sysdep.c:246
#8  0x00003f6a in _dl_start_final (arg=0x1026000, bootstrap_map_p=0x1025e50, 
    start_time=0) at rtld.c:249
#9  0x00003edb in _dl_start (arg=0x1026000) at rtld.c:201
(gdb) 


And I don't know where to go from here.  So, it's time to post. =)

-- 
Abandon the search for truth; settle for a good fantasy.