On Mon, Mar 11, 2002 at 04:37:27AM -0500, Roland McGrath wrote:
> > I did only the above tests, not a full install and boot, which one should
> > probably do next. But it already looks very promising, fine work!
>
> But it doesn't sound like you tested any of the dynamic loading
> functionality at all.
Indeed! module.c isn't even part of the compiled source in your branch.
I added module.c to the sources, and module to the store-types, although the
latter doesn't seem to be necessary. I removed gunzip.c from the sources,
and some of the GZIP objects, except util.o, which is also needed by bunzip2
(so I guess the current rule to build bunzip2 module is broken). I changed
libstore.so-LDLIBS += -ldl
to
libstore.so-LDFLAGS += -ldl
as the former is not recognized by our Makeconf. That made it build
correctly. I then made a libstore_gunzip.so.0.2. I changed
#define STORE_SONAME_SUFFIX ".so.1"
to
#define STORE_SONAME_SUFFIX ".so.0.2"
because otherwise it would look for the wrong file. From the command line,
it seems to recognize the gunzip store now, both with -T module gunzip:file.gz
and with -T gunzip file.gz. As a storeio translator, it starts up and dies:
#0 0x00007e04 in _dl_lookup_symbol () from /lib/ld.so
#1 0x011e08f3 in _dl_sym (handle=0x102b530, name=0x105cdaf
"__start_store_std_classes", who=0x0)
at dl-sym.c:62
#2 0x0121b108 in dlsym_doit (a=0x124b9fc) at dlsym.c:39
#3 0x0000bf92 in _dl_catch_error () from /lib/ld.so
#4 0x0121b426 in _dlerror_run (operate=0x121b0e4 <dlsym_doit>, args=0x124b9fc) at
dlerror.c:130
#5 0x0121b143 in dlsym (handle=0x102b530, name=0x105cdaf "__start_store_std_classes")
at dlsym.c:51
#6 0x010515e3 in store_find_class (name=0x804e1f0 "r.gz", clname_end=0x804e1f4 "",
classes=0x0)
at ../../libstore/typed.c:75
#7 0x010516e0 in store_typed_open (name=0x804e1f0 "r.gz", flags=4096, classes=0x0,
store=0x124bac8) at ../../libstore/typed.c:121
#8 0x0002ac07 in store_gunzip_open (name=0x804e1f0 "r.gz", flags=0, classes=0x0,
store=0x124fe8c)
at ../../libstore/gunzip.c:261
#9 0x010503ce in open (name=0x804e1f0 "r.gz", store=0x124fe8c) at
../../libstore/argp.c:188
#10 0x0105044c in store_parsed_open (parsed=0x804e1c8, flags=0, store=0x124fe8c)
at ../../libstore/argp.c:195
#11 0x08049f8e in dev_open (dev=0x124fe88) at ../../storeio/dev.c:153
#12 0x0804b64c in check_open_hook (trivfs_control=0x804e0f8, user=0x804e690, flags=1)
at ../../storeio/storeio.c:228
#13 0x0103487f in trivfs_S_fsys_getroot () from /lib/libtrivfs.so.0.2
#14 0x01034cbb in trivfs_S_fsys_syncfs () from /lib/libtrivfs.so.0.2
#15 0x010354cd in trivfs_fsys_server () from /lib/libtrivfs.so.0.2
#16 0x01031d5f in trivfs_demuxer () from /lib/libtrivfs.so.0.2
#17 0x01095fd3 in ports_manage_port_operations_one_thread () from /lib/libports.so.0.2
#18 0x010c30eb in __mach_msg_server_timeout (demux=0x124fdfc, max_size=8192,
rcv_name=31,
option=2048, timeout=0) at msgserver.c:127
#19 0x010960b6 in ports_manage_port_operations_one_thread () from /lib/libports.so.0.2
#20 0x010961a6 in ports_manage_port_operations_multithread () from /lib/libports.so.0.2
#21 0x0804b592 in main (argc=4, argv=0x124ff88) at ../../storeio/storeio.c:148
#22 0x010e4e2b in __libc_start_main (main=0x804b498 <main>, argc=4, ubp_av=0x124ff88,
init=0x804984c <_init>, fini=0x804c3e0 <_fini>, rtld_fini=0xc370 <_dl_fini>,
stack_end=0x124ff7c) at ../sysdeps/generic/libc-start.c:129
It turns out that in store_parsed_open, the gunzip store class is in parsed,
plus the name "r.gz". So NUM is 1, and it calls open as shown above. It
should fail to find a module and try to open it as a file instead, but
rather than doing that it crashes. It first finds the normal std classes,
and then at the second dlsym it dies. From an earlier debugging session:
75 start = dlsym (map, "__start_store_std_classes");
(gdb) print map
$1 = (struct link_map *) 0x102b000
(gdb) print *map
$2 = {l_addr = 0, l_name = 0x15aeb "", l_ld = 0x804da84, l_next = 0x102b500, l_prev =
0x0}
(gdb) n
76 if (start == 0)
(gdb) n
81 if (start == __start_store_std_classes)
(gdb) print start
$3 = (struct store_class **) 0x105fac0
(gdb) n
93 }
(gdb) n
75 start = dlsym (map, "__start_store_std_classes");
(gdb) n
Program received signal EXC_BAD_ACCESS, Could not access memory.
0x00007e04 in _dl_lookup_symbol () from /lib/ld.so
Note that -T gunzip file:r.gz works fine!
> But before those tests, if a full boot and tests on the system using the
> new libstore all work, then I will merge the branch into the mainline.
I did not do that yet.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' Debian http://www.debian.org [EMAIL PROTECTED]
Marcus Brinkmann GNU http://www.gnu.org [EMAIL PROTECTED]
[EMAIL PROTECTED]
http://www.marcus-brinkmann.de
_______________________________________________
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
