A better way to get runtime coverage with libprofile_rt (from compiler_rt) / gcov?

Hi all, In order to adapt an existing process to clang, I went and tried to figure out how to get coverage generation to work on FreeBSD with shared binaries (not static binaries), which is the default for clang/gcc: https://github.com/yaneurabeya/scratch/blob/master/coverage-with-shared

Re: Failed to build rescue with gcc 4.9

On Apr 3, 2015, at 14:10, Warner Losh wrote: >> >> On Apr 3, 2015, at 2:39 PM, Ed Maste wrote: >> >> On 3 April 2015 at 13:02, Warner Losh wrote: >>> That shows that something in the list is needed. Likely only crunchhide. >>> >>> It doesn’t tell us why we need it, or when we started needing

Re: Fails to build sys/i386/boot2 with gcc 4.9

> On Mar 29, 2015, at 15:56, Warner Losh wrote: > >> On Mar 29, 2015, at 2:29 PM, Craig Rodrigues wrote: >> >> On Sun, Mar 29, 2015 at 11:04 AM, Warner Losh wrote: >> >> If we built a UFS1-only boot2, that would fit in the 7.5k we have left >> to play with. We could then build a UFS2-only bo

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

On Mar 22, 2015, at 15:09, Dimitry Andric wrote: > On 22 Mar 2015, at 23:04, Garrett Cooper wrote: >> >> On Mar 22, 2015, at 15:01, Craig Rodrigues wrote: >> >> ... >> >>> OK, converting expr.y to use unsigned integers would require a bit of work.

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

On Mar 22, 2015, at 15:01, Craig Rodrigues wrote: ... > OK, converting expr.y to use unsigned integers would require a bit of work. > > Can you commit your patch to the Makefile? It fixes the problem for now. +1 I’d still like to know why clang 3.5 doesn’t have this behavior though — there

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

On Mar 22, 2015, at 14:36, Dimitry Andric wrote: > On 22 Mar 2015, at 22:32, Craig Rodrigues wrote: >> >> On Sun, Mar 22, 2015 at 2:29 PM, Dimitry Andric wrote: >> >> Ah right, that was on i386, on amd64 it does result in -2^63. It is indeed >> caused by reliance on signed integer wrapping.

Re: Jenkins build is still unstable: FreeBSD_HEAD-tests2 #867

On Mar 22, 2015, at 14:02, Craig Rodrigues wrote: > On Sun, Mar 22, 2015 at 11:26 AM, wrote: > >> See >> > > Can someone with toolchain expertise look at this? > After the clang 3.6.1 import, /bin/expr behaves differently. > > With c

Re: Failed to build with external toolchain

On Mar 7, 2015, at 12:12, Craig Rodrigues wrote: > Hi, > > I ran the build again and this time I am getting errors about undefined > symbol utimensat(): > > https://jenkins.freebsd.org/job/FreeBSD_HEAD_external_toolchain_gcc/14/console > > Any ideas? You might need to specify more options to

Re: Build failed in Jenkins: Build-UFS-image #599

On Dec 5, 2014, at 16:52, jenkins-ad...@freebsd.org wrote: > See I’m not entirely sure why the "could not determine COMPILER_TYPE" error popped up, but I have a couple of questions/concerns related to the makefile snippet. 1

Re: Unable to build world w/o clang on 11

> On Nov 11, 2014, at 07:51, Chris H wrote: > > On Mon, 10 Nov 2014 19:52:48 -0800 "Chris H" wrote > >> On Mon, 10 Nov 2014 19:22:31 -0800 Steve Kargl >> wrote >> On Mon, Nov 10, 2014 at 06:37:35PM -0800, Chris H wrote: ===> lib/libdpv (depend) rm -f .depend CC='cc ' mkd

Re: Building clang in buildworld as part of the bootstrap process -- is it really necessary?

> tl;dr: NO. Makes sense. I'll do some poking around and see if things could potentially be optimized with the clang build. On beefy machines it's not a big deal, but as we know on machines without a ton of memory or SSDs, it can become painful, as expected. Thanks :)! -Garrett __

Building clang in buildworld as part of the bootstrap process -- is it really necessary?

Hi all, One of the questions that came up from a co-worker is "why do I need to build clang in buildworld if I already installed it from ports"? I could see some valid reasons for doing this (one needs a cross-compiler, one might need specific options that might not be set in the ports version)

Bootstrap-related build failure with gcc due to change in sctp system headers; not with clang (was Re: svn commit: r269527 - in head: lib/libc/net sys/netinet)

On Aug 4, 2014, at 1:07 PM, Michael Tuexen wrote: > Author: tuexen > Date: Mon Aug 4 20:07:35 2014 > New Revision: 269527 > URL: http://svnweb.freebsd.org/changeset/base/269527 > > Log: > Add support for the SCTP_RECONFIG_SUPPORTED and the corresponding > sysctl controlling the negotiation of

Help with review/commit of conf/189156?

onf/189156: include/Makefile does not honor MK_GSSAPI == no To: Garrett Cooper Thank you very much for your problem report. It has the internal identification `conf/189156'. The individual assigned to look at your report is: freebsd-bugs. You can access the state of your problem report at

Re: svn commit: r250719 - in head: . usr.bin/make

On May 16, 2013, at 2:26 PM, Simon J. Gerraty wrote: > Author: sjg > Date: Thu May 16 21:26:46 2013 > New Revision: 250719 > URL: http://svnweb.freebsd.org/changeset/base/250719 > > Log: > Reverse the sense of the test wrt bmake, and guard against > MK_BMAKE not being defined. I forgot

Fwd: conf/178421: [PATCH] compile_et needs to be built with bootstrap-tools for buildworld when WITH_KERBEROS is set

, 2013 8:10:00 AM PDT > To: Garrett Cooper > Reply-To: freebsd-gnats-sub...@freebsd.org, freebsd-b...@freebsd.org > > Thank you very much for your problem report. > It has the internal identification `conf/178421'. > The individual assigned to look at your > report is: f

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

On May 7, 2013, at 10:09 PM, Warner Losh wrote: > > On May 7, 2013, at 9:42 PM, Garrett Cooper wrote: > >> On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper wrote: >> >> On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: >> >> On May 7, 2013, at 2:46 PM,

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

On Tue, May 7, 2013 at 2:26 PM, Garrett Cooper wrote: > > On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: > >> >> On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: >> >> > On May 7, 2013, at 1:39 PM, Brooks Davis wrote: >> > >> >>

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

On Tue, May 7, 2013 at 2:00 PM, Warner Losh wrote: > > On May 7, 2013, at 2:46 PM, Garrett Cooper wrote: > > > On May 7, 2013, at 1:39 PM, Brooks Davis wrote: > > > >> On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: > >>> Hi, > >&g

Re: clang doesn't make temporary files in all instances, causes build races by not using mk*temp(3) in /tmp

On Tue, May 7, 2013 at 1:58 PM, Garrett Cooper wrote: > Hi Dimitriy, > I ran into the following error when trying to execute make > tinderbox with FreeBSD svn head with ATF changes I'm going to push to > benno@: > > cc -O -pipe -DHAVE_CONFIG_H > -I/scratch/freebs

clang doesn't make temporary files in all instances, causes build races by not using mk*temp(3) in /tmp

Hi Dimitriy, I ran into the following error when trying to execute make tinderbox with FreeBSD svn head with ATF changes I'm going to push to benno@: cc -O -pipe -DHAVE_CONFIG_H -I/scratch/freebsd/head-svn/gnu/lib/libgomp -I. -I/scratch/freebsd/head-svn/gnu/lib/libgomp/../../../contrib/gccli

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

On May 7, 2013, at 1:39 PM, Brooks Davis wrote: > On Tue, May 07, 2013 at 01:05:07PM -0700, Garrett Cooper wrote: >> Hi, >>A common pattern that I've seen at Isilon and something else that I've >> wanted to have for a while is the ability to designate where

Re: [RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

On Tue, May 7, 2013 at 1:12 PM, Xin Li wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > On 05/07/13 13:05, Garrett Cooper wrote: > > Hi, A common pattern that I've seen at Isilon and something else > > that I've wanted to have for a while is the

[RFC] adding a variable to .mk and Makefile.inc1 to point to top of the FreeBSD source tree

Hi, A common pattern that I've seen at Isilon and something else that I've wanted to have for a while is the ability to designate where the top of a source tree was. This is important and helpful when dealing with source files that build upon each other or depend on sources located in other sec

Re: Fwd: docs/178286: [PATCH] document the LOCAL_* vars in build(7)

On Wed, May 1, 2013 at 3:07 PM, Brooks Davis wrote: > > On Wed, May 01, 2013 at 02:35:17PM -0700, Garrett Cooper wrote: >> Hi Brooks and Joel, >> I'd really appreciate if you guys could help out with this. I'm >> having to fix the Isilon build system due to

Fwd: docs/178286: [PATCH] document the LOCAL_* vars in build(7)

;ll shoot along more patches as I can. Thanks, -Garrett -- Forwarded message -- From: Date: Wed, May 1, 2013 at 2:30 PM Subject: Re: docs/178286: [PATCH] document the LOCAL_* vars in build(7) To: Garrett Cooper Thank you very much for your problem report. It has the internal

Re: [RFC] [Optionally] build tests with buildworld

On Apr 24, 2013, at 9:23 AM, Brooks Davis wrote: >> … >> Hi Brooks! >> Does this look ok? Most of the MK_TESTS logic has been shoved into >> bsd.own.mk and NO_TESTS is sprinkled around Makefile.inc1 as recommended. >> Thanks! >> -Garrett > > The functional parts seem fine. Some comments b

Re: [RFC] [Optionally] build tests with buildworld

On Apr 23, 2013, at 10:28 AM, Garrett Cooper wrote: > On Apr 23, 2013, at 9:59 AM, Brooks Davis wrote: > >> On Fri, Apr 19, 2013 at 11:17:50PM -0700, Garrett Cooper wrote: >>> Hi arch@ and toolchain@, >>> One of the items that I'm proposing be added to

Re: [RFC] [Optionally] build tests with buildworld

Hi Brooks! On Apr 23, 2013, at 9:59 AM, Brooks Davis wrote: > On Fri, Apr 19, 2013 at 11:17:50PM -0700, Garrett Cooper wrote: >> Hi arch@ and toolchain@, >>One of the items that I'm proposing be added to Makefile.inc1 in >> order to make building and installing

Re: [RFC] [Optionally] build tests with buildworld

On Apr 19, 2013, at 11:17 PM, Garrett Cooper wrote: > Hi arch@ and toolchain@, >One of the items that I'm proposing be added to Makefile.inc1 in > order to make building and installing tests on CURRENT (ATF and > otherwise) is a build knob called TESTS_WITH_WORLD (the name

[RFC] [Optionally] build tests with buildworld

Hi arch@ and toolchain@, One of the items that I'm proposing be added to Makefile.inc1 in order to make building and installing tests on CURRENT (ATF and otherwise) is a build knob called TESTS_WITH_WORLD (the name can be modified), which allows me to build and install various tests on my git b

Re: [RFC] teach config(8) about KERNCONFDIR

On Wed, Dec 5, 2012 at 9:23 PM, Garrett Cooper wrote: > (Sorry in advance for GMail mangling). > > I recently moved all of my svn trees to git and in order to ensure > that my trees are in as pristine a state as possible I've started > setting KERNCONFDIR=/root in /etc/sr

[RFC] teach config(8) about KERNCONFDIR

(Sorry in advance for GMail mangling). I recently moved all of my svn trees to git and in order to ensure that my trees are in as pristine a state as possible I've started setting KERNCONFDIR=/root in /etc/src.conf and I specify KERNCONF?= -DEBUG. This works pretty well in a standard setup (when

Fwd: [head tinderbox] failure on amd64/amd64

FYI.. these errors LINT errors have popped up on amd64/i386/pc98. -- Forwarded message -- From: FreeBSD Tinderbox Date: Tue, Nov 6, 2012 at 12:29 AM Subject: [head tinderbox] failure on amd64/amd64 To: FreeBSD Tinderbox , curr...@freebsd.org, am...@freebsd.org TB --- 2012-11-06

Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program

On Sep 24, 2012, at 1:21 AM, "Poul-Henning Kamp" wrote: > In message > > , Garrett Cooper writes: > >> No difference proven at 95.0% confidence > > This is the important bit of information... Yeah.. It's been a few moons since I've taken stati

Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program

On Sat, Sep 22, 2012 at 11:30 PM, Poul-Henning Kamp wrote: > In message > > , Garrett Cooper writes: > >>Without the change: >> >>$ python calc_runtime.py bw.*_without.log | ministat -w 72 >>[...] >>$ python calc_runtime.py bw.*.log | ministat -w

Re: [CFT/RFC]: refactor bsd.prog.mk to understand multiple programs instead of a singular program

On Sun, Sep 2, 2012 at 11:01 PM, Garrett Cooper wrote: > Hello, > I've been a bit busy working on porting over ATF from NetBSD, and > one of the pieces that's currently not available in FreeBSD that's > available in NetBSD is the ability to understand and compile mu

Re: Compiler performance tests on FreeBSD 10.0-CURRENT

On Sat, Sep 15, 2012 at 10:19 PM, Konstantin Belousov wrote: > On Sun, Sep 16, 2012 at 12:34:45AM +0200, Dimitry Andric wrote: >> Hi all, >> >> By request, I performed a series of kernel performance tests on FreeBSD >> 10.0-CURRENT, particularly comparing the runtime performance of GENERIC >> kern

Re: Clang as default compiler November 4th

On Tue, Sep 11, 2012 at 1:44 PM, Mark Linimon wrote: > On Tue, Sep 11, 2012 at 10:07:04AM +0100, David Chisnall wrote: >> There is some logic in the clang driver already for knowing when it is >> invoked as gcc. I'd be quite tempted to make gcc a symlink to clang >> and make clang default to gnu8

Re: Clang as default compiler November 4th

On Sep 11, 2012, at 8:35 AM, Daniel Eischen wrote: > On Tue, 11 Sep 2012, Konstantin Belousov wrote: > >> On Tue, Sep 11, 2012 at 02:06:49PM +0200, Roman Divacky wrote: >>> >>> We currently dont compile 4680 ports (out of 23857). Top 10 ports that >>> prevent >>> the most other ports from compi

Re: [rfc] a few kern.mk and bsd.sys.mk related changes

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 __

Re: [rfc] a few kern.mk and bsd.sys.mk related changes

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

Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS

On Thu, Apr 7, 2011 at 2:22 PM, Alexander Best wrote: > On Thu Apr  7 11, Garrett Cooper wrote: >> On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrote: >> > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best >> > wrote: >> >> hi there, >> >>

Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS

On Thu, Apr 7, 2011 at 1:53 PM, Garrett Cooper wrote: > On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best wrote: >> hi there, >> >> i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will >> let >> tinderbox fail, if any new kernel code

Re: [RFC] adding -Wmissing-include-dirs to CWARNFLAGS

On Thu, Apr 7, 2011 at 11:55 AM, Alexander Best wrote: > hi there, > > i'd like to propose adding -Wmissing-include-dirs to CWARNFLAGS. this will let > tinderbox fail, if any new kernel code was committed with (a) broken include > dir(s). > > i ran a test via > > make toolchains > make MAKE_JUST_K