Bug #524

Making world with gcc41?

Added by wa1ter almost 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-

Description

I put CCVER=gcc41 in make.conf, and I get this error during
make buildworld:

make: don't know how to make
/usr/obj/usr/src/world_i386/usr/src/gnu/lib/gcc41/libstdc++/../libiberty/libiberty.a.

Has anyone else tried gcc41 yet? Simon?

struct-by-reference.diff Magnifier (27.9 KB) corecode, 01/21/2007 11:44 AM

History

#1 Updated by swildner almost 8 years ago

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

Sascha

#2 Updated by corecode almost 8 years ago

fixed

#3 Updated by wa1ter almost 8 years ago

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?

#4 Updated by swildner almost 8 years ago

I've committed a fix.

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

Sascha

#5 Updated by swildner almost 8 years ago

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

#6 Updated by corecode almost 8 years ago

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

#7 Updated by wa1ter almost 8 years ago

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!

#8 Updated by corecode almost 8 years ago

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

#9 Updated by dillon almost 8 years ago

: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

#10 Updated by wa1ter almost 8 years ago

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?

#11 Updated by wa1ter almost 8 years ago

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?

#12 Updated by dillon almost 8 years ago

: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
<>

#13 Updated by corecode almost 8 years ago

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

cheers
simon

#14 Updated by corecode almost 8 years ago

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

Also available in: Atom PDF