[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thomas Schwinge
Subject: Re: [PATCH] Building the Hurd with gcc-4.0
Date: Fri, 16 Sep 2005 03:23:00 +0200
User-agent: Mutt/

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:
$ settrans -acg image0 
settrans: /home/tschwinge/tmp/hurd/hurd-ams-branch.gcc-3.3/ext2fs/ext2fs: 
Translator died

image0.img was created issueing
$ dd if=/dev/null of=image0.img bs=1M count=0 seek=100 && mke2fs -o hurd -b 
4096 image0.img
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
but the `ext2fs' segfaults after setting '*bootstrap = ~0' and continuing
in gdb:
 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 
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 
51        if (diskfs_boot_filesystem ())
56            task_get_bootstrap_port (mach_task_self (), bootstrap);
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 ();
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
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 
        err = 1024
        read = 45408
#5  0x080559a0 in create_disk_pager () at 
        upi = (struct user_pager_info *) 0x805c710
#6  0x0804dd95 in main (argc=1024, argv=0x400) at 
        err = 1024
        bootstrap = 4294967295

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?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]