[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
ldd misreports some apps as not dynamic
From: |
Jeff Bailey |
Subject: |
ldd misreports some apps as not dynamic |
Date: |
Tue, 16 Oct 2001 21:15:58 -0700 |
User-agent: |
Mutt/1.2.5i |
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.
- ldd misreports some apps as not dynamic,
Jeff Bailey <=