On Wed, Sep 07, 2005 at 09:51:26AM +0300, Ognyan Kulev wrote: > Thomas Schwinge wrote: > > The system stayed usable after installing the files, running > > /hurd/ext2fs by hand didn't raise a segmentation fault. > > OK, thanks. I didn't invest much time in gcc 4.0 then but just switched > to 3.3 :-)
Did you get that one to work? For me, there's really stange things going on. It seems that I'm not at all able to build a working `ext2fs' that is not statically linked. I tried various combinations of gcc (gcc-3.3 and gcc-4.0), CFLAGS (unset, '-pipe -O1 -g', '-pipe -O2 -g'), with and without my Hurd v.s. GCC-4.0 patches, even downgrading glibc, stripping the executables, using four different, quite freshly and thus cleanly installed systems; one of them a cross compiled one (also trying both gcc-3.3 and gcc-4.0). I could get the statically compiled (using gcc-4.0!) `ext2fs' to work, but not a single one of the various dynamically liked ones I built. I didn't do extensive tests to the working, statically linked ones, but the translator is set up correctly and I can list the node's contents. Trying to use a dynamically linked one (e.g. built using gcc-3.3), using the ams-branch--using the current Debian package's source gives the same results--looks like this: #v+ $ settrans -acg image0 /home/tschwinge/tmp/hurd/hurd-ams-branch.gcc-3.3/ext2fs/ext2fs /home/tschwinge/tmp/image0.img settrans: /home/tschwinge/tmp/hurd/hurd-ams-branch.gcc-3.3/ext2fs/ext2fs: Translator died #v- image0.img was created issueing #v+ $ dd if=/dev/null of=image0.img bs=1M count=0 seek=100 && mke2fs -o hurd -b 4096 image0.img #v- Using a file filled with 100MiB of zeros--GNU Mach at it's best: "104857600 bytes transferred in 88.710000 seconds (1182027 bytes/sec)"-- gave exactly the same results, as I expected. I tried debugging the thing using Neal's "Manually Bootstrapping a Translator" <URL:http://web.walfield.org/pub/people/neal/papers/hurd-misc/manual-bootstrap.txt> but the `ext2fs' segfaults after setting '*bootstrap = ~0' and continuing in gdb: #v+ [EMAIL PROTECTED]:~/tmp/hurd/hurd-ams-branch.gcc-3.3/ext2fs$ LD_LIBRARY_PATH=.:../libdiskfs/:../libfshelp/:../libhurdbugaddr/:../libihash/:../libiohelp/:../libpager/:../libports/:../libshouldbeinlibc/:../libstore/:../libthreads/ gdb ./ext2fs GNU gdb 6.3-debian [...] This GDB was configured as "i386-gnu"... (gdb) break main Breakpoint 1 at 0x804dd13: file ../../hurd-ams-branch/ext2fs/ext2fs.c, line 172. (gdb) run ~/tmp/image0.img Starting program: /devl3/tschwinge/tmp/hurd/hurd-ams-branch.gcc-3.3/ext2fs/ext2fs ~/tmp/image0.img Breakpoint 1, main (argc=2, argv=0x2) at ../../hurd-ams-branch/ext2fs/ext2fs.c:172 172 store = diskfs_init_main (&startup_argp, argc, argv, (gdb) step [...] diskfs_init_main (startup_argp=0x805b46c, argc=1, argv=0x1, store_parsed=0x805c2c4, bootstrap=0x127fd10) at ../../hurd-ams-branch/libdiskfs/init-main.c:51 51 if (diskfs_boot_filesystem ()) (gdb) 56 task_get_bootstrap_port (mach_task_self (), bootstrap); (gdb) 57 if (*bootstrap == MACH_PORT_NULL) (gdb) print bootstrap $1 = (mach_port_t *) 0x127fd10 (gdb) print *bootstrap $2 = 0 (gdb) print *bootstrap = ~0 $3 = 4294967295 (gdb) step 62 err = diskfs_init_diskfs (); (gdb) diskfs_init_diskfs () at ../../hurd-ams-branch/libdiskfs/init-init.c:60 60 if (diskfs_boot_filesystem ()) (gdb) break fsys_startup Breakpoint 2 at 0x1252274 (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0114bd6f in memcpy () from /lib/libc.so.0.3 (gdb) bt full #0 0x0114bd6f in memcpy () from /lib/libc.so.0.3 No symbol table info available. #1 0x01253a19 in io_read () from /lib/libhurduser.so.0.3 No symbol table info available. #2 0x010607f5 in file_byte_read (store=0x400, addr=1024, index=0, amount=1024, buf=0x400, len=0x400) at ../../hurd-ams-branch/libstore/file.c:229 No locals. #3 0x0105ab74 in store_read (store=0x805c5d0, addr=1024, amount=1024, buf=0x805c2d0, len=0x127fca4) at ../../hurd-ams-branch/libstore/rdwr.c:196 index = 0 base = 0 run = (struct store_run *) 0x805c638 runs_end = (struct store_run *) 0x805c648 block_shift = 0 read = 0x10607b0 <file_byte_read> #4 0x0804eea5 in get_hypermetadata () at ../../hurd-ams-branch/ext2fs/hyper.c:70 err = 1024 read = 45408 #5 0x080559a0 in create_disk_pager () at ../../hurd-ams-branch/ext2fs/pager.c:1189 upi = (struct user_pager_info *) 0x805c710 #6 0x0804dd95 in main (argc=1024, argv=0x400) at ../../hurd-ams-branch/ext2fs/ext2fs.c:182 err = 1024 bootstrap = 4294967295 #v- Andrew Resch reported on IRC that he experienced similar (the same?) issues when trying to build `ext2fs' a few months ago; so this is most probably not related to the current tool chain. I really don't get this, since Michael Banck is able to produce working Debian packages of the Hurd and Alfred M. Szmidt was--today--building and running a new, partly complete snapshot of the GNU system. Any ideas? Regards, Thomas _______________________________________________ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
