Re: [PATCH] Building the Hurd with gcc-4.0

[Thomas Schwinge]

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+
tschwinge@flubber:~/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