From owner-freebsd-toolchain@FreeBSD.ORG Mon May 30 16:35:29 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E19ED106566B for ; Mon, 30 May 2011 16:35:29 +0000 (UTC) (envelope-from rdivacky@vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [46.28.110.116]) by mx1.freebsd.org (Postfix) with ESMTP id A8BC98FC0A for ; Mon, 30 May 2011 16:35:29 +0000 (UTC) Received: by vlakno.cz (Postfix, from userid 1002) id D17F27F39B0; Mon, 30 May 2011 18:19:05 +0200 (CEST) Date: Mon, 30 May 2011 18:19:05 +0200 From: Roman Divacky To: Pan Tsu Message-ID: <20110530161905.GA91202@freebsd.org> References: <86zkm74srn.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <86zkm74srn.fsf@gmail.com> User-Agent: Mutt/1.4.2.3i Cc: freebsd-toolchain@freebsd.org Subject: Re: [clang] boot2 fails to build with DEBUG_FLAGS? X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 16:35:30 -0000 I dont have the same environment (I am using trunk llvm/clang) but I cant reproduce it here... fwiw, with trunk llvm DEBUG_FLAGS dies in assembly stage because our as does not know .cfi_section On Sat, May 28, 2011 at 03:40:12AM +0400, Pan Tsu wrote: > While compiling boot blocks with debug symbols may not be very useful > having DEBUG_FLAGS in make.conf is not uncommon. > > $ make CC=clang DEBUG_FLAGS=-g > [...] > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=16ed text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1f7d text=200 data=1d7d org=0 entry=0 > -381 bytes available > *** Error code 1 > > $ make CC=clang > [...] > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=1505 text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1d95 text=200 data=1b95 org=0 entry=0 > 107 bytes available > [...] > > $ make CC=gcc DEBUG_FLAGS=-g > [...] > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=13bd text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1c4d text=200 data=1a4d org=0 entry=0 > 435 bytes available > [...] > > $ make CC=gcc > [...] > objcopy -S -O binary boot2.out boot2.bin > btxld -v -E 0x2000 -f bin -b /usr/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin > kernel: ver=1.02 size=690 load=9000 entry=9010 map=16M pgctl=1:1 > client: fmt=bin size=13bd text=0 data=0 bss=0 entry=0 > output: fmt=bin size=1c4d text=200 data=1a4d org=0 entry=0 > 435 bytes available > [...] > > -- > FreeBSD 9.0-CURRENT #0 r222354M amd64 > _______________________________________________ > freebsd-toolchain@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-toolchain > To unsubscribe, send any mail to "freebsd-toolchain-unsubscribe@freebsd.org" From owner-freebsd-toolchain@FreeBSD.ORG Mon May 30 17:44:28 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 3F1D41065674 for ; Mon, 30 May 2011 17:44:28 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id A7D658FC0A for ; Mon, 30 May 2011 17:44:27 +0000 (UTC) Received: (qmail 18921 invoked by uid 0); 30 May 2011 17:44:26 -0000 Received: from 67.206.163.100 by rms-us004.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 30 May 2011 17:44:22 +0000 From: "Dieter BSD" Message-ID: <20110530174423.95220@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org,freebsd-toolchain@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: QOHQeVBt62mhIQ/aCmA5McRCRzdyMoOj Cc: Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 17:44:28 -0000 > maybe we find some nice -Wwarning options which are reasonable > to have -Wmissing-declarations -Wimplicit FreeBSD's gcc doesn't seem to have  -Wcoercion  ??? Bugzilla indicates that it was added years ago (2006?). It would be really really nice if -static worked on (nearly) everything. > and - most importantly - don't break tinderbox That's a matter of fixing the bugs before adding the warning flags to tinderbox. Ports need attention.  The warnings I get there are frightening. From owner-freebsd-toolchain@FreeBSD.ORG Mon May 30 18:27:29 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id A62781065673; Mon, 30 May 2011 18:27:29 +0000 (UTC) Date: Mon, 30 May 2011 18:27:29 +0000 From: Alexander Best To: Dieter BSD Message-ID: <20110530182729.GA94451@freebsd.org> References: <20110530174423.95220@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110530174423.95220@gmx.com> Cc: freebsd-hackers@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 18:27:29 -0000 On Mon May 30 11, Dieter BSD wrote: > > maybe we find some nice -Wwarning options which are reasonable > > to have > > -Wmissing-declarations > -Wimplicit > > FreeBSD's gcc doesn't seem to have  -Wcoercion  ??? > Bugzilla indicates that it was added years ago (2006?). -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc trunk and it's not in the gcc(1) manual. [1] http://gcc.gnu.org/wiki/Wcoercion > > It would be really really nice if -static worked on (nearly) everything. > > > and - most importantly - don't break tinderbox > > That's a matter of fixing the bugs before adding the warning flags > to tinderbox. > > Ports need attention.  The warnings I get there are frightening. -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Mon May 30 18:36:03 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 13252106567B for ; Mon, 30 May 2011 18:36:03 +0000 (UTC) (envelope-from utisoft@gmail.com) Received: from mail-bw0-f54.google.com (mail-bw0-f54.google.com [209.85.214.54]) by mx1.freebsd.org (Postfix) with ESMTP id 8D55B8FC08 for ; Mon, 30 May 2011 18:36:02 +0000 (UTC) Received: by bwz12 with SMTP id 12so4547373bwz.13 for ; Mon, 30 May 2011 11:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:reply-to:in-reply-to:references :from:date:message-id:subject:to:cc:content-type :content-transfer-encoding; bh=kL+W3q3uyk45rDnB2rHKzMyV26h/hoYGP4OWHbEx8J4=; b=EHpdJb4kTcW7DttHSi8ZRhOd7pJpRm2T/KI0oZ5MVVq42OEkU8lDJsffY86PBsqr4B nnoadt1AsxnO5kGJEuhLaQMnFyXesmkSNOULshhOjYjs4/HPFlNAfhu3gpWjrrO91PRd 7uAImxftQTkgkkK70DGt+wwU+vJlIP+4eCuQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:reply-to:in-reply-to:references:from:date:message-id :subject:to:cc:content-type:content-transfer-encoding; b=dmsr0414g4eXjFT3ielzlTQPMNySHfQYC55FYGFvxeqa9K+AmEEjujd7LjTlxsELKr LCk37+EUMfpVmMv1yI+zSHp2nMpuIboBbFaEWwKtem6mY2P4V6LsaW90LCouwhr65w7P tIubkATBcmDc585PJNv/FEkLoO2dNErMax0Tw= Received: by 10.204.82.149 with SMTP id b21mr4533117bkl.196.1306778673353; Mon, 30 May 2011 11:04:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.66.81 with HTTP; Mon, 30 May 2011 11:04:03 -0700 (PDT) In-Reply-To: <20110530174423.95220@gmx.com> References: <20110530174423.95220@gmx.com> From: Chris Rees Date: Mon, 30 May 2011 19:04:03 +0100 Message-ID: To: Dieter BSD Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: freebsd-hackers@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: utisoft@gmail.com List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 18:36:03 -0000 On 30 May 2011 18:44, Dieter BSD wrote: >> maybe we find some nice -Wwarning options which are reasonable >> to have > > -Wmissing-declarations > -Wimplicit > > FreeBSD's gcc doesn't seem to have =A0-Wcoercion =A0??? > Bugzilla indicates that it was added years ago (2006?). > > It would be really really nice if -static worked on (nearly) everything. > >> and - most importantly - don't break tinderbox > > That's a matter of fixing the bugs before adding the warning flags > to tinderbox. > > Ports need attention. =A0The warnings I get there are frightening. I find it comforting that they're just that: warnings. How do they frighten you? Chris From owner-freebsd-toolchain@FreeBSD.ORG Mon May 30 22:44:00 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 423E9106566B for ; Mon, 30 May 2011 22:44:00 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.mail.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id AAB788FC12 for ; Mon, 30 May 2011 22:43:59 +0000 (UTC) Received: (qmail 9551 invoked by uid 0); 30 May 2011 22:43:58 -0000 Received: from 67.206.161.57 by rms-us005.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Mon, 30 May 2011 22:43:55 +0000 From: "Dieter BSD" Message-ID: <20110530224357.95220@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org,freebsd-toolchain@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: mS/TeltcynCoPwXIBmBn/g9vcmZ1Zlxg Cc: Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 May 2011 22:44:00 -0000 Chris writes: >> Ports need attention. The warnings I get there are frightening. > > I find it comforting that they're just that: warnings. > > How do they frighten you? High quality code does not have any warnings. The most frightening thing is the attitute that "They're just warnings, so I'll ignore them."  Most compiler warnings should be fatal errors. And a lot of the warnings that require a -Wwhatever should be on by default. Code that doesn't compile cleanly often has other problems, like assuming that all CPUs are ILP32 little endian, like not checking return codes, etc. But hey, the next time the weather service issues a tornado warning, feel free to go outside and fly a kite.  After all it's just a warning. a13x writes: > -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc > trunk and it's not in the gcc(1) manual. > > [1] http://gcc.gnu.org/wiki/Wcoercion And yet someone marked the bug fixed. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 09:57:42 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 3A79F1065678; Tue, 31 May 2011 09:57:42 +0000 (UTC) Date: Tue, 31 May 2011 09:57:42 +0000 From: Alexander Best To: Bruce Cran Message-ID: <20110531095742.GA99888@freebsd.org> References: <20110527115147.GA73802@freebsd.org> <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20110528202619.GA27204@muon.cran.org.uk> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-toolchain@FreeBSD.ORG, Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 09:57:42 -0000 On Sat May 28 11, Bruce Cran wrote: > On Sat, May 28, 2011 at 06:23:26PM +0000, Alexander Best wrote: > > > > well i'm not an expert on this. but are we 100% sure that a kernel on amd64 > > compiled with -O2 frename-registers can be debugged the same way as one with > > -O? if that is the case: sure...-O2 is fine. ;) > > > > however i've often read messages - mostly by bruce evans - claiming that > > anything greater than -O will in fact decrease a kernel's ability to be > > debugged just as well as a kernel with -O. > > > > The critical option when -O2 is used is -fno-omit-frame-pointers, since removing > frame pointers makes debugging impossible (on i386). With -O2 code is moved around and > removed, so debugging is more difficult, but can still provide useful > information. any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as standard COPTFLAGS with debugging enabled for *all* archs? > > -- > Bruce Cran -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 10:37:06 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 90FD5106564A; Tue, 31 May 2011 10:37:06 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 179008FC14; Tue, 31 May 2011 10:37:06 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26] (unknown [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 0EDFD5C37; Tue, 31 May 2011 12:37:04 +0200 (CEST) Message-ID: <4DE4C4CC.4020905@FreeBSD.org> Date: Tue, 31 May 2011 12:37:00 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18pre) Gecko/20110527 Lanikai/3.1.11pre MIME-Version: 1.0 To: Alexander Best References: <20110527115147.GA73802@freebsd.org> <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> In-Reply-To: <20110531095742.GA99888@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@FreeBSD.ORG, freebsd-toolchain@FreeBSD.ORG, Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 10:37:06 -0000 On 2011-05-31 11:57, Alexander Best wrote: ... >>> however i've often read messages - mostly by bruce evans - claiming that >>> anything greater than -O will in fact decrease a kernel's ability to be >>> debugged just as well as a kernel with -O. >> The critical option when -O2 is used is -fno-omit-frame-pointers, since removing >> frame pointers makes debugging impossible (on i386). With -O2 code is moved around and >> removed, so debugging is more difficult, but can still provide useful >> information. > any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing as > standard COPTFLAGS with debugging enabled for *all* archs? Most likely, the performance gain from -O2 is rather small, except for special cases, but the pain during debugging is increased a great deal. Even if you add frame pointers, with -O2 large pieces of code can be transformed, variables or even entire functions can be completely eliminated, and so on, making debugging much more difficult. From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 10:46:39 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id C2AF91065670; Tue, 31 May 2011 10:46:39 +0000 (UTC) Date: Tue, 31 May 2011 10:46:39 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110531104639.GA4218@freebsd.org> References: <20110527115147.GA73802@freebsd.org> <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4DE4C4CC.4020905@FreeBSD.org> Cc: freebsd-hackers@FreeBSD.ORG, freebsd-toolchain@FreeBSD.ORG, Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 10:46:39 -0000 On Tue May 31 11, Dimitry Andric wrote: > On 2011-05-31 11:57, Alexander Best wrote: > ... > >>>however i've often read messages - mostly by bruce evans - claiming that > >>>anything greater than -O will in fact decrease a kernel's ability to be > >>>debugged just as well as a kernel with -O. > >>The critical option when -O2 is used is -fno-omit-frame-pointers, since > >>removing > >>frame pointers makes debugging impossible (on i386). With -O2 code is > >>moved around and > >>removed, so debugging is more difficult, but can still provide useful > >>information. > >any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing > >as > >standard COPTFLAGS with debugging enabled for *all* archs? > > Most likely, the performance gain from -O2 is rather small, except for > special cases, but the pain during debugging is increased a great deal. > > Even if you add frame pointers, with -O2 large pieces of code can be > transformed, variables or even entire functions can be completely > eliminated, and so on, making debugging much more difficult. *lol* we're moving in circles. so back to the beginning: why not use -O for all archs, if debugging was enabled? for amd64 -O2 is always set, no matter, if debugging is enabled or disabled. cheers. alex -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 11:16:47 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 1233) id AA6C3106566C; Tue, 31 May 2011 11:16:47 +0000 (UTC) Date: Tue, 31 May 2011 11:16:47 +0000 From: Alexander Best To: Dieter BSD Message-ID: <20110531111647.GA7168@freebsd.org> References: <20110530224357.95220@gmx.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20110530224357.95220@gmx.com> Cc: freebsd-hackers@freebsd.org, freebsd-toolchain@freebsd.org Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 11:16:47 -0000 On Mon May 30 11, Dieter BSD wrote: > Chris writes: > >> Ports need attention. The warnings I get there are frightening. > > > > I find it comforting that they're just that: warnings. > > > > How do they frighten you? > > High quality code does not have any warnings. > > The most frightening thing is the attitute that "They're just warnings, > so I'll ignore them."  Most compiler warnings should be fatal errors. > And a lot of the warnings that require a -Wwhatever should be on by > default. please keep in mind that -Wfoo does reflect the ideas of the GNU people regarding *proper* code. the warnings themselves are sometimes wrong, because they complain about perfectly correct code. so -Wfoo should not be considered a code verifier, but in fact what it is: a warning flag. sometimes it's correct and indeed reports wrong code, sometimes it is completely wrong. cheers. alex > > Code that doesn't compile cleanly often has other problems, like assuming > that all CPUs are ILP32 little endian, like not checking return codes, etc. > > But hey, the next time the weather service issues a tornado warning, > feel free to go outside and fly a kite.  After all it's just a warning. > > a13x writes: > > -Wcoercion seems to have only been a SoC project in 2006 [1]. i checked gcc > > trunk and it's not in the gcc(1) manual. > > > > [1] http://gcc.gnu.org/wiki/Wcoercion > > And yet someone marked the bug fixed. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 13:08:03 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E60801065670; Tue, 31 May 2011 13:08:03 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id BF8418FC0C; Tue, 31 May 2011 13:08:03 +0000 (UTC) Received: from fledge.watson.org (fledge.watson.org [65.122.17.41]) by cyrus.watson.org (Postfix) with ESMTPS id 5BC3746B39; Tue, 31 May 2011 09:08:03 -0400 (EDT) Date: Tue, 31 May 2011 14:08:03 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Alexander Best In-Reply-To: <20110531111647.GA7168@freebsd.org> Message-ID: References: <20110530224357.95220@gmx.com> <20110531111647.GA7168@freebsd.org> User-Agent: Alpine 2.00 (BSF 1167 2008-08-23) MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1637175785-1306847283=:14209" Cc: freebsd-hackers@freebsd.org, freebsd-toolchain@freebsd.org, Dieter BSD Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:08:04 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1637175785-1306847283=:14209 Content-Type: TEXT/PLAIN; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8BIT On Tue, 31 May 2011, Alexander Best wrote: > On Mon May 30 11, Dieter BSD wrote: >> Chris writes: >>>> Ports need attention. The warnings I get there are frightening. >>> >>> I find it comforting that they're just that: warnings. >>> >>> How do they frighten you? >> >> High quality code does not have any warnings. >> >> The most frightening thing is the attitute that "They're just warnings, so >> I'll ignore them."  Most compiler warnings should be fatal errors. And a >> lot of the warnings that require a -Wwhatever should be on by default. > > please keep in mind that -Wfoo does reflect the ideas of the GNU people > regarding *proper* code. the warnings themselves are sometimes wrong, > because they complain about perfectly correct code. so -Wfoo should not be > considered a code verifier, but in fact what it is: a warning flag. > sometimes it's correct and indeed reports wrong code, sometimes it is > completely wrong. And, it's also worth remembering that warnings change over time, as the compiler changes. One of the known issues building with clang is that large quantities of "warning-free code" under gcc are in fact rife with warnings under clang, including the gcc source code itself. In general, my hope is that we can get the FreeBSD base warning-free for a useful set of warnings, and on the whole, this is the case. Pretty much the entire kernel is compiled with quite a large number of warning classes enabled, and -Werror set, for example. (One of the other tensions, of course, is the locally maintained vs externally maintained tension: fixing warnings in other people's code is useful only if you can get them to accept the fixes back -- maintaining large numbers of patch sets over time is not sustainable for non-trivial quantifies of code, if you're tracking the upstream vendor. Ports is the worst possible case, where maintaining local patches is quite expensive. In the FreeBSD base we can do a lot better, since we can use revision control and automatic merging to help us, but it's still an overhead that has to be reasoned about carefully.) Robert --621616949-1637175785-1306847283=:14209-- From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 13:30:38 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 4A57F106564A for ; Tue, 31 May 2011 13:30:38 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 141BB8FC12 for ; Tue, 31 May 2011 13:30:37 +0000 (UTC) Received: by pwj8 with SMTP id 8so2586205pwj.13 for ; Tue, 31 May 2011 06:30:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=4D2Tk7ynIckQ02ADSQDYOl+6bKpZF+l/3gettiq9qUs=; b=WP4AIyiIonYsT4aVJaStgGwAmd2qh5I9sXHhJF1MiKYwUCOY9sQZLtSxAaTdQvg+J4 nTlIQBkTnqmPRd37U6qzRqEDWtudPUWfOfe2q1lLMU6KUk0cMFTGCFpiF+jajFG4a9ld TE6fQWuckT7VM4RAZH88Jcdk1MuoUXLV5DUE8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=mPZjvHF94ttUmGGXk6F/B6Nb72PfcpUrM/Bdcj/mH9qESOTDGsJLZ9LISYrCUURb/h m8yPOxSSGAUafllSKYRbZN3eAift03fHFKuzuXC764NrYe2R8WmZU0fwLcut48fgz2SV 9VqpGNi8lg43uCGU+5Bih0oWxoKTOdvE55Bpk= Received: by 10.68.14.74 with SMTP id n10mr1211710pbc.489.1306846921094; Tue, 31 May 2011 06:02:01 -0700 (PDT) Received: from [192.168.20.56] (c-24-6-49-154.hsd1.ca.comcast.net [24.6.49.154]) by mx.google.com with ESMTPS id i7sm35345pbj.10.2011.05.31.06.01.58 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 06:01:59 -0700 (PDT) References: <20110527115147.GA73802@freebsd.org> <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> In-Reply-To: <20110531104639.GA4218@freebsd.org> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> X-Mailer: iPhone Mail (8J2) From: Garrett Cooper Date: Tue, 31 May 2011 06:01:55 -0700 To: Alexander Best Cc: "freebsd-hackers@FreeBSD.ORG" , "freebsd-toolchain@FreeBSD.ORG" , Dimitry Andric , Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 13:30:38 -0000 On May 31, 2011, at 3:46 AM, Alexander Best wrote: > On Tue May 31 11, Dimitry Andric wrote: >> On 2011-05-31 11:57, Alexander Best wrote: >> ... >>>>> however i've often read messages - mostly by bruce evans - claiming th= at >>>>> anything greater than -O will in fact decrease a kernel's ability to b= e >>>>> debugged just as well as a kernel with -O. >>>> The critical option when -O2 is used is -fno-omit-frame-pointers, since= =20 >>>> removing >>>> frame pointers makes debugging impossible (on i386). With -O2 code is=20= >>>> moved around and >>>> removed, so debugging is more difficult, but can still provide useful >>>> information. >>> any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasi= ng=20 >>> as >>> standard COPTFLAGS with debugging enabled for *all* archs? >>=20 >> Most likely, the performance gain from -O2 is rather small, except for >> special cases, but the pain during debugging is increased a great deal. >>=20 >> Even if you add frame pointers, with -O2 large pieces of code can be >> transformed, variables or even entire functions can be completely >> eliminated, and so on, making debugging much more difficult. >=20 > *lol* we're moving in circles. so back to the beginning: why not use -O > for all archs, if debugging was enabled? for amd64 -O2 is always set, no > matter, if debugging is enabled or disabled. I don't know, but I've run into cases where gcc has inlined or shuffled arou= nd code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf to= use -O0 when DEBUG_FLAGS was defined. Thanks, -Garrett= From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 14:39:14 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id 12444106566B; Tue, 31 May 2011 14:39:14 +0000 (UTC) Date: Tue, 31 May 2011 14:39:14 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110531143914.GA30260@freebsd.org> References: <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> Cc: "freebsd-hackers@FreeBSD.ORG" , "freebsd-toolchain@FreeBSD.ORG" , Dimitry Andric , Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 14:39:14 -0000 On Tue May 31 11, Garrett Cooper wrote: > On May 31, 2011, at 3:46 AM, Alexander Best wrote: > > > On Tue May 31 11, Dimitry Andric wrote: > >> On 2011-05-31 11:57, Alexander Best wrote: > >> ... > >>>>> however i've often read messages - mostly by bruce evans - claiming that > >>>>> anything greater than -O will in fact decrease a kernel's ability to be > >>>>> debugged just as well as a kernel with -O. > >>>> The critical option when -O2 is used is -fno-omit-frame-pointers, since > >>>> removing > >>>> frame pointers makes debugging impossible (on i386). With -O2 code is > >>>> moved around and > >>>> removed, so debugging is more difficult, but can still provide useful > >>>> information. > >>> any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing > >>> as > >>> standard COPTFLAGS with debugging enabled for *all* archs? > >> > >> Most likely, the performance gain from -O2 is rather small, except for > >> special cases, but the pain during debugging is increased a great deal. > >> > >> Even if you add frame pointers, with -O2 large pieces of code can be > >> transformed, variables or even entire functions can be completely > >> eliminated, and so on, making debugging much more difficult. > > > > *lol* we're moving in circles. so back to the beginning: why not use -O > > for all archs, if debugging was enabled? for amd64 -O2 is always set, no > > matter, if debugging is enabled or disabled. > > I don't know, but I've run into cases where gcc has inlined or shuffled around code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf to use -O0 when DEBUG_FLAGS was defined. ...which leads me to the conclusion that -O should be set when DEBUG was defined: an all ARCHS. right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't -fno-omit-frame-pointer be set uncondtitionally on all archs? just like -fno-strict-aliasing? cheers. alex > Thanks, > -Garrett -- a13x From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 15:26:54 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id BA37D1065670; Tue, 31 May 2011 15:26:54 +0000 (UTC) Date: Tue, 31 May 2011 15:26:54 +0000 From: Alexander Best To: Garrett Cooper Message-ID: <20110531152654.GA42990@freebsd.org> References: <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="zhXaljGHf11kAtnf" Content-Disposition: inline In-Reply-To: <20110531143914.GA30260@freebsd.org> Cc: "freebsd-hackers@FreeBSD.ORG" , "freebsd-toolchain@FreeBSD.ORG" , Dimitry Andric , Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 15:26:54 -0000 --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue May 31 11, Alexander Best wrote: > On Tue May 31 11, Garrett Cooper wrote: > > On May 31, 2011, at 3:46 AM, Alexander Best wrote: > > > > > On Tue May 31 11, Dimitry Andric wrote: > > >> On 2011-05-31 11:57, Alexander Best wrote: > > >> ... > > >>>>> however i've often read messages - mostly by bruce evans - claiming that > > >>>>> anything greater than -O will in fact decrease a kernel's ability to be > > >>>>> debugged just as well as a kernel with -O. > > >>>> The critical option when -O2 is used is -fno-omit-frame-pointers, since > > >>>> removing > > >>>> frame pointers makes debugging impossible (on i386). With -O2 code is > > >>>> moved around and > > >>>> removed, so debugging is more difficult, but can still provide useful > > >>>> information. > > >>> any reason we cannot use -O2 -fno-omit-frame-pointers -fno-strict-aliasing > > >>> as > > >>> standard COPTFLAGS with debugging enabled for *all* archs? > > >> > > >> Most likely, the performance gain from -O2 is rather small, except for > > >> special cases, but the pain during debugging is increased a great deal. > > >> > > >> Even if you add frame pointers, with -O2 large pieces of code can be > > >> transformed, variables or even entire functions can be completely > > >> eliminated, and so on, making debugging much more difficult. > > > > > > *lol* we're moving in circles. so back to the beginning: why not use -O > > > for all archs, if debugging was enabled? for amd64 -O2 is always set, no > > > matter, if debugging is enabled or disabled. > > > > I don't know, but I've run into cases where gcc has inlined or shuffled around code on amd64 with -O2 -fno-strict-aliasing, so I changed my make.conf to use -O0 when DEBUG_FLAGS was defined. > > ...which leads me to the conclusion that -O should be set when DEBUG was > defined: an all ARCHS. > > right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the > kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't > -fno-omit-frame-pointer be set uncondtitionally on all archs? just like > -fno-strict-aliasing? so how about the following patch? cheers. alex > > cheers. > alex > > > Thanks, > > -Garrett > -- > a13x -- a13x --zhXaljGHf11kAtnf Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern.pre.mk.diff" diff --git a/sys/conf/Makefile.amd64 b/sys/conf/Makefile.amd64 index 5096829..f70f3de 100644 --- a/sys/conf/Makefile.amd64 +++ b/sys/conf/Makefile.amd64 @@ -31,13 +31,6 @@ S= ../../.. .endif .include "$S/conf/kern.pre.mk" -DDB_ENABLED!= grep DDB opt_ddb.h || true -DTR_ENABLED!= grep KDTRACE_FRAME opt_kdtrace.h || true -HWPMC_ENABLED!= grep HWPMC opt_hwpmc_hooks.h || true -.if !empty(DDB_ENABLED) || !empty(DTR_ENABLED) || !empty(HWPMC_ENABLED) -CFLAGS+= -fno-omit-frame-pointer -.endif - MKMODULESENV+= MACHINE=amd64 .if ${CC:T:Mclang} == "clang" diff --git a/sys/conf/Makefile.powerpc b/sys/conf/Makefile.powerpc index e4cd85f..04bc66b 100644 --- a/sys/conf/Makefile.powerpc +++ b/sys/conf/Makefile.powerpc @@ -37,11 +37,6 @@ INCLUDES+= -I$S/contrib/libfdt CFLAGS+= -msoft-float -DDB_ENABLED!= grep DDB opt_ddb.h || true -.if !empty(DDB_ENABLED) -CFLAGS+= -fno-omit-frame-pointer -.endif - %BEFORE_DEPEND %OBJS diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk index e9aa6e2..0314ada 100644 --- a/sys/conf/kern.pre.mk +++ b/sys/conf/kern.pre.mk @@ -24,26 +24,28 @@ OBJCOPY?= objcopy SIZE?= size .if defined(DEBUG) -_MINUS_O= -O +COPTFLAGS?= -O -pipe CTFFLAGS+= -g +.elif ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang" +COPTFLAGS?= -O2 -frename-registers -pipe .else -_MINUS_O= -O2 +COPTFLAGS?= -O2 -pipe .endif -.if ${MACHINE_CPUARCH} == "amd64" -COPTFLAGS?=-O2 -frename-registers -pipe -.else -COPTFLAGS?=${_MINUS_O} -pipe + +.if !empty(COPTFLAGS:M-O[234sz]) && empty(COPTFLAGS:M-fno-strict-aliasing) +COPTFLAGS+= -fno-strict-aliasing .endif -.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) -COPTFLAGS+= -fno-strict-aliasing + +.if empty(COPTFLAGS:M-O0) && empty(COPTFLAGS:M-fno-omit-frame-pointer) +COPTFLAGS+= -fno-omit-frame-pointer .endif + .if !defined(NO_CPU_COPTFLAGS) -COPTFLAGS+= ${_CPUCFLAGS} +COPTFLAGS+= ${_CPUCFLAGS} .endif -C_DIALECT= -std=c99 -NOSTDINC= -nostdinc -INCLUDES= ${NOSTDINC} ${INCLMAGIC} -I. -I$S +C_DIALECT= -std=c99 +INCLUDES= -nostdinc ${INCLMAGIC} -I. -I$S # This hack lets us use the OpenBSD altq code without spamming a new # include path into contrib'ed source files. @@ -146,8 +148,7 @@ SYSTEM_LD_TAIL= @${OBJCOPY} --strip-symbol gcc2_compiled. ${.TARGET} ; \ ${SIZE} ${.TARGET} ; chmod 755 ${.TARGET} SYSTEM_DEP+= ${LDSCRIPT} -# MKMODULESENV is set here so that port makefiles can augment -# them. +# MKMODULESENV is set here so that port makefiles can augment them. MKMODULESENV+= MAKEOBJDIRPREFIX=${.OBJDIR}/modules KMODDIR=${KODIR} MKMODULESENV+= MACHINE_CPUARCH=${MACHINE_CPUARCH} --zhXaljGHf11kAtnf-- From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 18:32:57 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 46E871065673; Tue, 31 May 2011 18:32:57 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id 01C2A8FC0C; Tue, 31 May 2011 18:32:57 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26] (unknown [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id 012075C37; Tue, 31 May 2011 20:32:55 +0200 (CEST) Message-ID: <4DE53450.10109@FreeBSD.org> Date: Tue, 31 May 2011 20:32:48 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18pre) Gecko/20110527 Lanikai/3.1.11pre MIME-Version: 1.0 To: Alexander Best References: <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> In-Reply-To: <20110531143914.GA30260@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu , "freebsd-hackers@FreeBSD.ORG" Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:32:57 -0000 On 2011-05-31 16:39, Alexander Best wrote: ... > ...which leads me to the conclusion that -O should be set when DEBUG was > defined: an all ARCHS. > > right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the > kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? shouldn't > -fno-omit-frame-pointer be set uncondtitionally on all archs? No, not unconditionally on all archs. Some arches have no problem debugging when gcc's frame pointer is turned off, namely arm, ia64, mips, powerpc and sparc, if I read the source correctly. On these arches, even -O already sets -fomit-frame-pointer. So, for all arches, if DEBUG is enabled, we could just use -O (as default only, if the user wants to override this for whatever reason, it should be honoured). > just like > -fno-strict-aliasing? That should only be needed in combination with -O2, if that is the default optimization (e.g. if DEBUG is not enabled). IMHO this option should not be forced, if users specify their own CFLAGS/COPTFLAGS. Summarizing, I would suggest: - If DEBUG is enabled, use plain -O by default, on all arches - If DEBUG is disabled, use -O2 -fno-strict-aliasing by default, on all arches. From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 18:45:58 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id F08AF1065674; Tue, 31 May 2011 18:45:58 +0000 (UTC) (envelope-from dim@FreeBSD.org) Received: from tensor.andric.com (cl-327.ede-01.nl.sixxs.net [IPv6:2001:7b8:2ff:146::2]) by mx1.freebsd.org (Postfix) with ESMTP id ABD308FC1F; Tue, 31 May 2011 18:45:58 +0000 (UTC) Received: from [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26] (unknown [IPv6:2001:7b8:3a7:0:4518:389f:3ae0:4d26]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by tensor.andric.com (Postfix) with ESMTPSA id BDA7A5C37; Tue, 31 May 2011 20:45:57 +0200 (CEST) Message-ID: <4DE5375F.1050400@FreeBSD.org> Date: Tue, 31 May 2011 20:45:51 +0200 From: Dimitry Andric Organization: The FreeBSD Project User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18pre) Gecko/20110527 Lanikai/3.1.11pre MIME-Version: 1.0 To: Alexander Best References: <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> <20110531152654.GA42990@freebsd.org> In-Reply-To: <20110531152654.GA42990@freebsd.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu , "freebsd-hackers@FreeBSD.ORG" Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:45:59 -0000 On 2011-05-31 17:26, Alexander Best wrote: ... > so how about the following patch? Could you please try to not mix spacing and style changes with functional changes in this patch? It makes it more difficult to review. From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 18:47:44 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A156D1065673; Tue, 31 May 2011 18:47:44 +0000 (UTC) (envelope-from yanegomi@gmail.com) Received: from mail-pw0-f54.google.com (mail-pw0-f54.google.com [209.85.160.54]) by mx1.freebsd.org (Postfix) with ESMTP id 569958FC15; Tue, 31 May 2011 18:47:43 +0000 (UTC) Received: by pwj8 with SMTP id 8so2763592pwj.13 for ; Tue, 31 May 2011 11:47:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:references:in-reply-to:mime-version :content-transfer-encoding:content-type:message-id:cc:x-mailer:from :subject:date:to; bh=THxt1CEpaOZeKC4LuL29e/Hzcmh9Z1ZFZpRH1rY/Xus=; b=bNpa1OlUrmdbbQSWpwG3iRvgGnOxmJpGC57U+Rgq66y652VmOQUixVQX4a9+LX8CxV QuhUnHN4t+MDCfZsxq+EWcft+1qDWwXztbQ9e7mfrEbdqw+/q2oRpJzYaep14ZdmC1qF Mjx+c3DZqRuHKjaIME7aUMJZSByKkEZwSQ2ac= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=references:in-reply-to:mime-version:content-transfer-encoding :content-type:message-id:cc:x-mailer:from:subject:date:to; b=vKtCZoWYQMECbxuB48UdhiFcVY1nsI1hsSJKw3i0PtSuCqitJS4EoXGRgyg8kyA46F clO4gm70qos1YdWxIOj8aM6f68rfoTaf7hV13L7kit28WXTvyeYxOHg6BIY8+fgwm+Ts JzxBbo1GKuqRFgzcEUXXrWz8+2WCYrS4NhxFU= Received: by 10.142.152.34 with SMTP id z34mr1169615wfd.197.1306867663698; Tue, 31 May 2011 11:47:43 -0700 (PDT) Received: from [173.37.1.90] (dhcp-173-37-1-90.cisco.com [173.37.1.90]) by mx.google.com with ESMTPS id q13sm165789wfd.23.2011.05.31.11.47.41 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 31 May 2011 11:47:42 -0700 (PDT) References: <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> <20110531152654.GA42990@freebsd.org> <4DE5375F.1050400@FreeBSD.org> In-Reply-To: <4DE5375F.1050400@FreeBSD.org> Mime-Version: 1.0 (iPhone Mail 8J2) Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Message-Id: <43542F98-E35C-48D0-A582-40CD31F0056D@gmail.com> X-Mailer: iPhone Mail (8J2) From: Garrett Cooper Date: Tue, 31 May 2011 11:47:37 -0700 To: Dimitry Andric Cc: Alexander Best , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu , "freebsd-hackers@FreeBSD.ORG" Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:47:44 -0000 On May 31, 2011, at 11:45 AM, Dimitry Andric wrote: > On 2011-05-31 17:26, Alexander Best wrote: > ... >> so how about the following patch? > > Could you please try to not mix spacing and style changes with > functional changes in this patch? It makes it more difficult to review. +1 From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 19:18:20 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:4f8:fff6::35]) by hub.freebsd.org (Postfix) with ESMTP id 0EA7C106566C; Tue, 31 May 2011 19:18:20 +0000 (UTC) (envelope-from dougb@FreeBSD.org) Received: from 65-241-43-5.globalsuite.net (hub.freebsd.org [IPv6:2001:4f8:fff6::36]) by mx2.freebsd.org (Postfix) with ESMTP id 1019314E236; Tue, 31 May 2011 19:18:16 +0000 (UTC) Message-ID: <4DE53EF7.2080603@FreeBSD.org> Date: Tue, 31 May 2011 12:18:15 -0700 From: Doug Barton Organization: http://SupersetSolutions.com/ User-Agent: Mozilla/5.0 (X11; U; FreeBSD amd64; en-US; rv:1.9.2.17) Gecko/20110429 Thunderbird/3.1.10 MIME-Version: 1.0 To: Alexander Best References: <3BF63174-1B29-4A4D-96DD-3ED65ED96EAC@bsdimp.com> <20110527181459.GA29908@freebsd.org> <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> In-Reply-To: <20110531143914.GA30260@freebsd.org> X-Enigmail-Version: 1.1.2 OpenPGP: id=1A1ABC84 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Garrett Cooper , "freebsd-hackers@FreeBSD.ORG" , Dimitry Andric , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 19:18:20 -0000 On 05/31/2011 07:39, Alexander Best wrote: > ...which leads me to the conclusion that -O should be set when DEBUG was > defined: an all ARCHS. +1 -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 20:00:06 2011 Return-Path: Delivered-To: freebsd-toolchain@FreeBSD.ORG Received: by hub.freebsd.org (Postfix, from userid 1233) id B89641065674; Tue, 31 May 2011 20:00:06 +0000 (UTC) Date: Tue, 31 May 2011 20:00:06 +0000 From: Alexander Best To: Dimitry Andric Message-ID: <20110531200006.GA74380@freebsd.org> References: <20110527182906.GA31871@freebsd.org> <86oc2mlsey.fsf@gmail.com> <20110528182326.GA75447@freebsd.org> <20110528202619.GA27204@muon.cran.org.uk> <20110531095742.GA99888@freebsd.org> <4DE4C4CC.4020905@FreeBSD.org> <20110531104639.GA4218@freebsd.org> <24ADBA34-A5FC-4A67-8D6F-3BDAE158285C@gmail.com> <20110531143914.GA30260@freebsd.org> <4DE53450.10109@FreeBSD.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline In-Reply-To: <4DE53450.10109@FreeBSD.org> Cc: Garrett Cooper , "freebsd-toolchain@FreeBSD.ORG" , Pan Tsu , "freebsd-hackers@FreeBSD.ORG" Subject: Re: [rfc] a few kern.mk and bsd.sys.mk related changes X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 20:00:06 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue May 31 11, Dimitry Andric wrote: > On 2011-05-31 16:39, Alexander Best wrote: > ... > >...which leads me to the conclusion that -O should be set when DEBUG was > >defined: an all ARCHS. > > > >right now -fno-omit-frame-pointer is only set on amd64 and powerpc, if the > >kernel contains DDB, KDTRACE_FRAME or HWPMC. how about this behavior? > >shouldn't > >-fno-omit-frame-pointer be set uncondtitionally on all archs? > > No, not unconditionally on all archs. Some arches have no problem > debugging when gcc's frame pointer is turned off, namely arm, ia64, > mips, powerpc and sparc, if I read the source correctly. > > On these arches, even -O already sets -fomit-frame-pointer. > > So, for all arches, if DEBUG is enabled, we could just use -O (as > default only, if the user wants to override this for whatever reason, it > should be honoured). > > > >just like > >-fno-strict-aliasing? > > That should only be needed in combination with -O2, if that is the > default optimization (e.g. if DEBUG is not enabled). IMHO this option > should not be forced, if users specify their own CFLAGS/COPTFLAGS. > > Summarizing, I would suggest: > > - If DEBUG is enabled, use plain -O by default, on all arches > - If DEBUG is disabled, use -O2 -fno-strict-aliasing by default, on all > arches. thanks for your suggestions. i've incorporated them into the patch. one thing i'm unsure is: what should be done when the user *doesn't* define DEBUG, but has DDB, KDTRACE_FRAME or HWPMC in his kernel config? the current behavior is to set -fno-omit-frame-pointer on amd64 and powerpc. i think this behavior shouldn't be change. even though the user didn't specify DEBUG, the fact that he has those kernel options indicates that he wants to do some kind of debugging imho. cheers. alex ps: sorry for the extra whitespace changes! -- a13x --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="kern.pre.mk.diff" diff --git a/sys/conf/kern.pre.mk b/sys/conf/kern.pre.mk index e9aa6e2..e6beda8 100644 --- a/sys/conf/kern.pre.mk +++ b/sys/conf/kern.pre.mk @@ -24,18 +24,12 @@ OBJCOPY?= objcopy SIZE?= size .if defined(DEBUG) -_MINUS_O= -O +COPTFLAGS?= -O -pipe CTFFLAGS+= -g +.elif ${MACHINE_CPUARCH} == "amd64" && ${CC:T:Mclang} != "clang" +COPTFLAGS?= -O2 -fno-strict-aliasing -frename-registers -pipe .else -_MINUS_O= -O2 -.endif -.if ${MACHINE_CPUARCH} == "amd64" -COPTFLAGS?=-O2 -frename-registers -pipe -.else -COPTFLAGS?=${_MINUS_O} -pipe -.endif -.if !empty(COPTFLAGS:M-O[23s]) && empty(COPTFLAGS:M-fno-strict-aliasing) -COPTFLAGS+= -fno-strict-aliasing +COPTFLAGS?= -O2 -fno-strict-aliasing -pipe .endif .if !defined(NO_CPU_COPTFLAGS) COPTFLAGS+= ${_CPUCFLAGS} --CE+1k2dSO48ffgeK-- From owner-freebsd-toolchain@FreeBSD.ORG Tue May 31 23:39:16 2011 Return-Path: Delivered-To: freebsd-toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EB6E91065673 for ; Tue, 31 May 2011 23:39:16 +0000 (UTC) (envelope-from dieterbsd@engineer.com) Received: from mailout-us.gmx.com (mailout-us.gmx.com [74.208.5.67]) by mx1.freebsd.org (Postfix) with SMTP id 9377B8FC1D for ; Tue, 31 May 2011 23:39:16 +0000 (UTC) Received: (qmail 28635 invoked by uid 0); 31 May 2011 23:38:57 -0000 Received: from 67.206.163.29 by rms-us007.v300.gmx.net with HTTP Content-Type: text/plain; charset="utf-8" Date: Tue, 31 May 2011 23:38:53 +0000 From: "Dieter BSD" Message-ID: <20110531233855.95190@gmx.com> MIME-Version: 1.0 To: freebsd-hackers@freebsd.org,freebsd-toolchain@freebsd.org X-Authenticated: #74169980 X-Flags: 0001 X-Mailer: GMX.com Web Mailer x-registered: 0 Content-Transfer-Encoding: 8bit X-GMX-UID: ag2MIl0dlTXuAivrAW5lMhRjaGRhZlq2 Cc: Subject: Re: compiler warnings (was: Re: [rfc] a few kern.mk and bsd.sys.mk related changes) X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 23:39:17 -0000 >> please keep in mind that -Wfoo does reflect the ideas of the GNU people >> regarding *proper* code. the warnings themselves are sometimes wrong, >> because they complain about perfectly correct code. I attempted to get the gcc people to improve this: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9072 Most of the warnings I see are either due to someone thinking all the world is ILP32 and doing things like storing a 64 bit pointer or long in a 32 bit int, or due to the compiler needing more info to insure that they are not trying to stuff 64 bits into 32, such as missing prototypes.  Either way it needs to be fixed. In many cases the developers that claim to write such great code, and claim that the compiler warnings don't matter are the ones whose code has the most bugs (seg faults, floating point exceptions, ...). > Pretty much the entire kernel is compiled > with quite a large number of warning classes enabled, and -Werror set, for > example. Whoever did this, THANK YOU!!! > fixing warnings in other people's code is useful only if > you can get them to accept the fixes back Fixing bugs is always useful.  Certainly it is a *lot* more efficient if you can get them fixed at the source rather than having to maintain patches.