DragonFlyBSD

I think it's rather WANT_GCC41 which causes this (i.e., fails with 3.4 too).

Sascha

fixed

On Sat, 20 Jan 2007, Simon 'corecode' Schubert wrote:

Thanks, Simon. Buildworld works fine now, and even my custom kernel
builds -- but there is one sound module which fails with gcc41:

/usr/src/sys/dev/sound/driver/hda/../../../../dev/sound/pci/hda/hdac.c:255:
error: static declaration of 'M_HDAC' follows non-static declaration
@/dev/sound/pci/hda/hdac_private.h:90: error: previous declaration of 'M_HDAC'
was here

BTW, the stripped kernel is actually smaller using gcc41:
3065336 --> 2991515. (The debug kernel is a bit larger with gcc41, but
I don't think that is anything to criticize.)

Is there any reason to stay with gcc34 as the default any longer?

I've committed a fix.

Yes, a good one even: Running a 4.1 kernel doesn't work yet. :)

Sascha

Here's the panic string Peter Avalos got when he tried to boot a kernel
compiled with 4.1:

http://leaf.dragonflybsd.org/~pavalos/gcc41-kernel.crash

Sascha

Okay, I fixed it, lets go for some explanation first:

The gpfault comes from vm86_bioscall(...) in init386(). The cause is that the assembler code passes the struct vm86frame by value, i.e. simply creating it on the stack. This worked up to gcc34, but gcc41 now optimizes stores to unused memory locations away, whis is allowed per the standards. This led to an uninitialized stack frame which in turn panicked the box.

After some time of bug searching (qemu with gdbserver being very helpful) it turns out that freebsd did have the same problem one month ago. So, the fix is the same: pass structs by reference if you expect the callee to modify them.

The attached patch does this. It is quite a bit, but well, it needs to be done. Gcc41 kernel boots fine now. Best we get that in before release.

cheers
simon

On Sun, 21 Jan 2007, Simon 'corecode' Schubert wrote:

I just now tried your patch. Alas, I got a page fault during boot just
after "kern.seedenable 0 -> 1". Here is the trace, minus the lengthy
hexadecimal arguments (I'll transcribe them if you need them):

strlen
iconv_sysctl_drvlist
sysctl_root
userland_sysctl
syscall12
Xint0x80_syscall

I typed 'panic' at the db prompt, but nothing happened.
Any ideas, suggestions?

Thanks!

which modules do you load and which devices do you have compiled into your kernel?

what happens when you do "call dumpsys" on the db prompt?

cheers
simon

:Okay, I fixed it, lets go for some explanation first:
:
:The gpfault comes from vm86_bioscall(...) in init386(). The cause is tha=
:t the assembler code passes the struct vm86frame by value, i.e. simply cr=
:eating it on the stack. This worked up to gcc34, but gcc41 now optimizes=
: stores to unused memory locations away, whis is allowed per the standard=
:s. This led to an uninitialized stack frame which in turn panicked the b=
:ox.
:
:After some time of bug searching (qemu with gdbserver being very helpfu=
:l) it turns out that freebsd did have the same problem one month ago. So=
:, the fix is the same: pass structs by reference if you expect the calle=
:e to modify them.
:
:The attached patch does this. It is quite a bit, but well, it needs to b=
:e done. Gcc41 kernel boots fine now. Best we get that in before release=
:=2E
:
:cheers
: simon

Oooohh... I've actually been wanting to do that for a while.

Ok, please go ahead and commit it right now.

But this WILL mean we can't branch today.  Not with that big a change.
    We will have to branch tomorrow.

-Matt

On Mon, 22 Jan 2007, Simon 'corecode' Schubert wrote:

Aha! It was smbfs. I can now load the libiconv, libmchain, and smbfs
modules without a panic (which surprises me) but when I then try a
mount_smbfs I do get the panic. I'm not sure why I got the panic
during boot before, because I'm not trying to mount a smb fs at that
point (although I do start smbd during boot).

what happens when you do "call dumpsys" on the db prompt?

It worked just now, but only after I typed 'panic' and nothing
happened. Anyway, I watched the dump happen, but savecore did
nothing on the next boot, so I'm stumped.

#savecore /var/crash
savecore: /kernel: _dumpmag not in namelist

What does that mean?

Simon 'corecode' Schubert wrote:
..

http://leaf.dragonflybsd.org/~pavalos/gcc41-kernel.crash

Hi Simon,

After reading some of the recent posts about vkernel I began to think
that vkernel might be a good tool to find bugs like this. Maybe even
to debug my mount_smbfs panic? I dunno, what do you think?

:walt wrote:
:> After reading some of the recent posts about vkernel I began to think
:> that vkernel might be a good tool to find bugs like this. Maybe even
:> to debug my mount_smbfs panic? I dunno, what do you think?
:
:yes, that's exactly possible. but with the vkernel, you can't debug hard=
:ware drivers.
:
:cheers
: simon

Exactly.  You can even debug the vkernel with gdb on the process id
    (not kgdb).  Is that cool or what?

-Matt
                    Matthew Dillon 
                    <dillon@backplane.com>

yes, that's exactly possible. but with the vkernel, you can't debug hardware drivers.

cheers
simon

totally. qemu doesn't work 100% like that, but almost:

% qemu -hda disk.img
...
in qemu: ctrl-alt-2 (switches to qemu console)
qemu> gdbserver

on other console:
% gdb kernel.debug # the one booted from disk.img
gdb> target remote localhost:1234
gdb> bt

works excellent. well, interrupts sometimes confuse you debugging (every now and then you'll be in fastintr :)

definitely my choice for hardware driver debugging.

cheers
simon