Re: [CFT]: ClangBSD is selfhosting, we need testers now

On Wed, Apr 21, 2010 at 07:22:00PM +0200, Alexander Best wrote:
> Roman Divacky schrieb am 2010-04-21:
> > On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote:
> > > i might have stumbled upon a problem with clang. i've compiled a
> > > kernel from
> > > the clang branch using `make kernel INSTKERNNAME=clang` and booted
> > > from it.
> > > i'm now experiencing audio problems with mp3s and certain video
> > > files.
> > > playback is awfully slow and the audio output gets distorted
> > > massively. `top`
> > > however reports no high cpu load and `vmstat -i` doesn't report
> > > anything
> > > unusual either.
> 
> > > this problem doesn't occur with a regular gcc-kernel.
> 
> > > both kernels are running under a regular (gcc) world.
> 
> > > i thought it might be a problem with acpi, but disabling acpi
> > > (hint.acpi.0.disabled=1) gives me a system freeze.
> 
> > I've heard about this problem but did not manage to reproduce that.
> 
> > can you try to bisect what file is being miscompiled? ie. compile
> > half of the kernel with gcc and half with clang and bisect this
> > way to a single file.
> 
> > we can work from there...
> 
> i've identified the problem to be somewhere in sys/dev/sound. i've removed
> "device sound" and "device hda_snd" from my kernel config and
> rebuild/reinstalled both kernels (gcc and clang). i then booted the clang
> kernel and loaded various sound.ko and snd_hda.ko combination. here're the
> results:
> 
> sound.ko (clang) snd_hda.ko (clang) => BROKEN
> sound.ko (clang) snd_hda.ko (gcc)   => BROKEN
> sound.ko (gcc) snd_hda.ko (gcc)     => OK
> sound.ko (gcc) snd_hda.ko (clang)   => OK

great work! it looks like sound.ko is the culprit..

this is amd64 because my i386 kernel plays sound just fine.

could you try to bisect the sound.ko ?

you can do it this way:

1) cd modules/sound/sound && make CC=gcc

2) make -V SRCS | tr " " "\n" | grep -v \.h | sort | grep "^[a-m].*" | xargs touch

                                                            ^^^^^ this is your bisect pattern

3) make CC=clang && make install

4) reload the module && test the sound

5) if the sound works you swap your bisect pattern (ie. [a-m] -> [n-z] etc.)
   if not you know that you that the miscompiled file is in you pattern and 
   you can narrow it (ie. [a-m] -> [a-g] etc.)

6) goto 1 until you compile a single file

I am pretty sure you can understand this and reduce this to a single file.
once we get single file that is being miscompiled we can do some slightly
\more educated guess on whats going on and structure our testing a little
smarter...

thnx! roman