Date: Thu, 22 Apr 2010 21:26:11 +0200 (CEST) From: Alexander Best <alexbestms@wwu.de> To: Ulrich =?iso-8859-1?Q?Sp=F6rlein?= <uqs@spoerlein.net> Cc: Roman Divacky <rdivacky@FreeBSD.org>, freebsd-current@FreeBSD.org Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now Message-ID: <permail-201004221926111e86ffa800004086-a_best01@message-id.uni-muenster.de> In-Reply-To: <20100422141709.GV92627@acme.spoerlein.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Ulrich Sp=F6rlein schrieb am 2010-04-22:
> On Wed, 21.04.2010 at 23:30:15 +0200, Alexander Best wrote:
> > Roman Divacky schrieb am 2010-04-21:
> > > On Wed, Apr 21, 2010 at 09:44:45PM +0200, Alexander Best wrote:
> > > > Roman Divacky schrieb am 2010-04-21:
> > > > [snip]
> > > > > 1) cd modules/sound/sound && make CC=3Dgcc
> > > > after this step these are the sizes of sound.ko* in
> > > > modules/sound/sound:
> > > > -rw-r--r-- 1 root wheel 449120 Apr 21 21:36 sound.ko
> > > > -rw-r--r-- 1 root wheel 2284757 Apr 21 21:36 sound.ko.debug
> > > > -rw-r--r-- 1 root wheel 2055512 Apr 21 21:36
> > > > sound.ko.symbols
> > > > > 2) make -V SRCS | tr " " "\n" | grep -v \.h | sort | grep
> > > > > "^[a-m].*"
> > > > > | xargs touch
> > > this line is wrong.. it creates empty files which are used
> > > instead
> > > of touching the existing ones... it needs to be adjusted so it
> > > touches the files (thus forcing them to be rebuilt with the
> > > second
> > > make invocation)
> > i'm now 100% sure that buffer.c is causing the problem. what i did
> > to verify
> > this was:
> > cd sys/modules/sound/sound && make CC=3Dclang && touch
> > ../../../dev/sound/pcm/buffer.c && make CC=3Dgcc && make install
> > this gives me working sound!
> Great stuff to have narrowed it down so much. Next logical step would
> be
> to do the bisect on function-level scope.
> Copy one half of buffer.c to buffer-clang.c, the other half to
> buffer-gcc.c,
> adjust the Makefile to use buffer-{gcc,clang}.c instead of buffer.c
> and
> compile them accordingly. Redo your tests till we know the single
> function(s)
> where clang produces bad code.
thanks for the hint. i'll try and see if i can pinpoint the exact function =
in
buffer.c causing the problem.
> Hang in there, the hard part is almost done!
> Uli
--=20
Alexander Best
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?permail-201004221926111e86ffa800004086-a_best01>