[TESTING]: ClangBSD branch needs testing before the import to HEAD
Roman Divacky
ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import
into HEAD in roughly a week. We would like the initial import to be as painless
as possible and therefore we ask you to test ClangBSD to assure that the revision
we are importing does not have some really embarassing bugs.
How to do it (on i386 and amd64):
0) install fresh devel/llvm-devel port
1) svn co http://svn.freebsd.org/base/projects/clangbsd src
2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf
3) cd src && make buildworld
4) make installworld DESTDIR=/usr/clangbsd
5) (optional) try to build kernel with clang and boot it
5.1) cd /sys/{arch}/conf
5.2) config YOUR_KERNEL
5.3) setenv CC clang in tcsh or export CC=clang in bash
5.4) cd ../compile/YOUR_KERNEL
5.5) make && make install
please make sure that it builds (on amd64/i386) and that the resulting world
is runnable. ie. try to chroot into it and "do stuff". ie.
chroot /clangbsd /bin/tcsh
... stuff ...
there's a wiki page on this effort: http://wiki.freebsd.org/BuildingFreeBSDWithClang
please report back any problems/success to me and/or this mailing list.
thank you for your testing!
Roman Divacky on behalf of the ClangBSD team
Kostik Belousov
> hi,
>
> ClangBSD was updated to LLVM/clang revision 104832 which is what we
> aim to import into HEAD in roughly a week. We would like the initial
the mailing list will happen. So far, nothing appeared on either
arch@ or current@ providing argumentation why should we accept this.
Scott Long
Sounds like you're inviting the discussion right now. I'll start =-)
1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been "good enough" for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough.
2. Due to the political bent of the GPL3 and the FSF's insistence on shoving it down everyone's throats, FreeBSD is stuck with a dead-end version of gcc. This has already been a liability in terms of addressing bugs in gcc itself, and it will only get worse as technology moves forward and gcc stands still.
3. Clang/LLVM has an active development base and a clear future. It will move forward while gcc rots. There simply is no future left in gcc unless the FreeBSD project decides to embrace the GPL3, and that's a move that has already been heavily discussed, debated, and decided on. Anecdotally, I think that FreeBSD is benefiting from shunning the GPL3; it's made it an attractive option for companies looking for an unencumbered OS for their products.
4. While Clang is immature now, it will mature in the near future, and FreeBSD will benefit from that process. FreeBSD will get built-in access to upcoming technologies like GCD+Blocks and better code editors and development tools that gcc will never support. It'll break free of the development stranglehold that exists within gcc. Clang has shown good agility in adapting to the needs of FreeBSD and the legacy of gcc, thanks in large part to the efforts of people like Roman. Gcc has been nothing but drama and headache, even with the valiant efforts of people like Alexander Kabaev.
5. If all of this turns out to not be true and Clang/LLVM fails, FreeBSD has lost nothing and can remove it from the base system. Gcc remains where it is for now, at least until it's time for the "remove gcc discussion".
The future is !gcc. Putting Clang+LLVM into a position where it can be easily embraced by FreeBSD users will greatly benefit the FreeBSD project.
Scott
_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
Brandon Gooch
> hi,
>
> ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import
I'm running on a "full" ClangBSD system (world and kernel), and I've
had no issues for the past couple of days. I've had the machine
working nearly constantly -- building new and updating installed
ports, running several ezjails (PostgreSQL, Apache 2.2, etc...), and
generally using/abusing my computer by watching Flash video on the
bsdconferences channel on YouTube...
So, what exactly should we expect, if anything, to break? :)
Is there anything more useful than an "it works" type of feedback that
a novice user like myself could provide?
And...
A Little Message To the ClangBSD Team:
As little more than a novice user, I realize that I don't have the
full picture of what moving from GCC to clang/llvm means to FreeBSD. I
don't have enough experience with either compiler technology or the
FreeBSD project to have a lot to say in any discussion or dialog
regarding the decisions to come. But I do trust the FreeBSD project as
a whole -- the technology and the people involved -- and it seems that
this is a mandatory step in order to continue to to enhance FreeBSD.
So thank you to the ClangBSD team for making awesome progress. It
makes me incredibly happy to see all those involved with ClangBSD,
especially Roman, stand up and steer FreeBSD toward the future.
Looking forward to it,
-Brandon
Kostik Belousov
> On May 30, 2010, at 7:58 AM, Kostik Belousov wrote:
> >> hi,
> >>
> >> ClangBSD was updated to LLVM/clang revision 104832 which is what we
> >> aim to import into HEAD in roughly a week. We would like the initial
> > the mailing list will happen. So far, nothing appeared on either
> > arch@ or current@ providing argumentation why should we accept this.
>
> Sounds like you're inviting the discussion right now. I'll start =-)
>
> 1. I hate gcc with the burning heat of a million suns. It's not a
> tool, it's a political weapon wielded by the FSF and their acolytes.
> It's also a crummy piece of software that has been "good enough" for
> far too long. Its development model is a burden to work with and has
> been a major liability towards FreeBSD releases in the past. Its
> demise cannot happen soon enough.
>
> 2. Due to the political bent of the GPL3 and the FSF's insistence
> on shoving it down everyone's throats, FreeBSD is stuck with a
> dead-end version of gcc. This has already been a liability in terms
> of addressing bugs in gcc itself, and it will only get worse as
> technology moves forward and gcc stands still.
>
> 3. Clang/LLVM has an active development base and a clear future. It
> will move forward while gcc rots. There simply is no future left in
> gcc unless the FreeBSD project decides to embrace the GPL3, and that's
> a move that has already been heavily discussed, debated, and decided
> on. Anecdotally, I think that FreeBSD is benefiting from shunning the
> GPL3; it's made it an attractive option for companies looking for an
> unencumbered OS for their products.
>
> 4. While Clang is immature now, it will mature in the near future,
> and FreeBSD will benefit from that process. FreeBSD will get built-in
> editors and development tools that gcc will never support. It'll break
> free of the development stranglehold that exists within gcc. Clang has
> shown good agility in adapting to the needs of FreeBSD and the legacy
> of gcc, thanks in large part to the efforts of people like Roman. Gcc
> has been nothing but drama and headache, even with the valiant efforts
> of people like Alexander Kabaev.
>
> 5. If all of this turns out to not be true and Clang/LLVM fails,
> FreeBSD has lost nothing and can remove it from the base system. Gcc
> remains where it is for now, at least until it's time for the "remove
> gcc discussion".
>
> The future is !gcc. Putting Clang+LLVM into a position where it can
> be easily embraced by FreeBSD users will greatly benefit the FreeBSD
> project.
>
> Scott
>
said could be labeled as distilled propaganda.
My main concern is the usefulness of HEAD for routine bug-fixing process.
The proposed merge makes it relatively easy for users to start compiling
the system with CLang. Our HEAD userbase is one of the most valuable
project asset to ensure the quality of the system. After the support for
easy compilation with clang is imported, some substantial portion of the
HEAD users definitely start experimenting with it. This immediately makes
the bug reports against HEAD almost useless, since level of demotivation
when looking at the bug is immense. When you do know that the issue can
be in the compiler, and not the OS, why looking ?
Any bug analisys now shall start with exchange to verify which compiler
was used to build the reporter system, and ask to reproduce it with gcc.
[I am talking not only about gnats, but also mailing list questions,
private pleas for help etc].
My personal opinion is that pushing the import now at the present state
of clang makes a disservice to FreeBSD, and possible clang. Why not keep
the glue on the branch as it is ? Motivated testers willing to help
definitely can checkout from the branch. Import can happen when we are
satisfied with the quality of new compiler, instead of discontent about
old one.
Rather, I would consider the changes to ease the use of any external
compiler, from ports or whatever, bent into shape and kept up to date
with system progress very important, much less controversial and more
useful. Then, addicts of any kool-aid-compiler can drink their potion
without starting undesired relations. Unfortunately, this is not what
happen.
Roman Divacky
people are reporting bugs coming from a compiler problem rather than
those from a genuine src problem?
people are already experimenting with clang installed from ports,
with gcc4.{3,4,5} from ports etc. by not importing clang we can
maybe delay this a little but it's coming anyway.
> My personal opinion is that pushing the import now at the present state
> of clang makes a disservice to FreeBSD, and possible clang. Why not keep
> the glue on the branch as it is ? Motivated testers willing to help
> definitely can checkout from the branch. Import can happen when we are
> satisfied with the quality of new compiler, instead of discontent about
> old one.
people have been testing stuff and identified bugs. those bugs were fixed.
there are sure some more but we need wider exposure to identify those
new bugs and also clasify them.
the amount of people who are willing and able to checkout and test external
branch is minimal. I feel we are at the point where more exposure is
necessary.
by importing we are sending a strong signal to various 3rd parties to show
in what way we are moving. importing sooner rather than later also ensures
that the compiler will get much more tested (and thus stable) by the day
9.0R happens.
> Rather, I would consider the changes to ease the use of any external
> compiler, from ports or whatever, bent into shape and kept up to date
> with system progress very important, much less controversial and more
> useful. Then, addicts of any kool-aid-compiler can drink their potion
> without starting undesired relations. Unfortunately, this is not what
> happen.
this is orthogonal to this. we as a project aim for delivering complete
operating system and we just need a system compiler. gcc4.2.1 just
cant serve us anymore, we need to do something now.
roman
Scott Long
>
> My personal opinion is that pushing the import now at the present state
> of clang makes a disservice to FreeBSD, and possible clang. Why not keep
> the glue on the branch as it is ? Motivated testers willing to help
> definitely can checkout from the branch. Import can happen when we are
> satisfied with the quality of new compiler, instead of discontent about
> old one.
Who is "we", and what is their criteria? Are you speaking for the entire FreeBSD project?
Scott
Kostik Belousov
is very strange and worrying that you, who are pushing the import, ask
somebody about plan on identifying and handling the compiler bugs. I
would expect you to have a solid plan before the import. This lowers my
confidence in the proposal even further.
>
> people are already experimenting with clang installed from ports,
> with gcc4.{3,4,5} from ports etc. by not importing clang we can
> maybe delay this a little but it's coming anyway.
I am pretty much fine and happy with people experimenting with clang
or any other compilers from ports, custom built, whatever. This is very
different from importing some compiler into base. See below about "signal".
>
> > My personal opinion is that pushing the import now at the present state
> > of clang makes a disservice to FreeBSD, and possible clang. Why not keep
> > the glue on the branch as it is ? Motivated testers willing to help
> > definitely can checkout from the branch. Import can happen when we are
> > satisfied with the quality of new compiler, instead of discontent about
> > old one.
>
> people have been testing stuff and identified bugs. those bugs were fixed.
> there are sure some more but we need wider exposure to identify those
> new bugs and also clasify them.
But I object to sacrificing the FreeBSD development and test cycle
to the clang development and test cycle. When the compiler becomes
stable enough to not think first about bug in the compiler, and only
then considering the bug in the compiled program, it can be used for
non-compiler development.
If somebody wants to do clang development, why should she develop it
in FreeBSD repo, or under the coverage of FreeBSD project, instead of
clang project ? Put it another way, why FreeBSD developer have to
debug clang instead of debugging FreeBSD ?
>
> the amount of people who are willing and able to checkout and test external
> branch is minimal. I feel we are at the point where more exposure is
> necessary.
>
> by importing we are sending a strong signal to various 3rd parties to show
> in what way we are moving. importing sooner rather than later also ensures
> that the compiler will get much more tested (and thus stable) by the day
> 9.0R happens.
Yes, we do send a signal, and the signal is too strong IMO.
>
> > Rather, I would consider the changes to ease the use of any external
> > compiler, from ports or whatever, bent into shape and kept up to date
> > with system progress very important, much less controversial and more
> > useful. Then, addicts of any kool-aid-compiler can drink their potion
> > without starting undesired relations. Unfortunately, this is not what
> > happen.
>
> this is orthogonal to this. we as a project aim for delivering complete
> operating system and we just need a system compiler. gcc4.2.1 just
> cant serve us anymore, we need to do something now.
Please describe why gcc in base cannot serve us anymore while served up
to the minute I got your message.
Attilio Rao
> of clang makes a disservice to FreeBSD, and possible clang. Why not keep
> the glue on the branch as it is ? Motivated testers willing to help
> definitely can checkout from the branch. Import can happen when we are
> satisfied with the quality of new compiler, instead of discontent about
> old one.
FWIW, I entirely agree with Kostik here.
I really would like to see CLANG more integrated with FreeBSD only
when there are 0 or similar (well-known, already analyzed, listed
somewhere, etc.) bugs by the compiler rather than still being in the
middle of a bug storm. Besides, the 'debugging problem' is pretty much
real and nobody answered with a reasonable solution for it, and being
honest, I don't see the people pushing for the import concerned about
that at all.
Are all the bug reports collected somewhere? What's the state of their
resolution? There is a description somewhere of missing support and
things still to be addressed?
Thanks,
Attilio
--
Peace can only be achieved by understanding - A. Einstein
Roman Divacky
> 2010/5/31 Kostik Belousov <kost...@gmail.com>:
> > On Mon, May 31, 2010 at 12:03:17AM -0600, Scott Long wrote:
> >> On May 30, 2010, at 7:58 AM, Kostik Belousov wrote:
> >> > On Sat, May 29, 2010 at 03:02:40PM +0200, Roman Divacky wrote:
> >> >> hi,
> >> >>
> >> >> ClangBSD was updated to LLVM/clang revision 104832 which is what we
> >> >> aim to import into HEAD in roughly a week. We would like the initial
> >> > It was promised that before the import, the public discussion on
> >> > the mailing list will happen. So far, nothing appeared on either
> >> > arch@ or current@ providing argumentation why should we accept this.
> >>
there are no known clang bugs (at least known to me) related to FreeBSD
in other words - at this point you can compile FreeBSD with clang (both
in the version in clangbsd) and it "works" (for people who tested it)
on amd64 and i386
roman
Attilio Rao
I don't mean about FreeBSD, but about CLANG itself.
It would be very depressing to loose many hours on kernel races before
to discover it was a compiler deficiency, for example.
Astrodog
have both compilers in base for some (presumably short) period of
time... then just have which one you use be a configuration option,
which should give LLVM/clang some additional exposure, without the
obvious risks of a complete switch. It should be relatively simply to
have "clang as a compile time option in base" then "clang as default
with gcc as an option" then "clang only", as it proves itself out
building the tree.
I don't really see how the ~50-100MB that only keeping one compiler
in base for a month or two (when there's not going to be a release
from HEAD anyway) would be worth it, when it's compared to the massive
cluster this is probably going to turn into, provided there's a
relatively easy way to opt out of either compiler.
As far as bug reports go, it's not as though this is some
unprecedented problem. In handling PRs, people are asked to rebuild
with patches, different settings, etc already. Its just one more thing
among a list of many to keep in mind when going through that process.
I don't think users of HEAD would find such a request unreasonable
(or, at least, any more unreasonable than what they already have to go
through sometimes.)
--- Harrison Grundy
Roman Divacky
> >
> > in other words - at this point you can compile FreeBSD with clang (both
> > in the version in clangbsd) and it "works" (for people who tested it)
> > on amd64 and i386
>
> I don't mean about FreeBSD, but about CLANG itself.
> It would be very depressing to loose many hours on kernel races before
> to discover it was a compiler deficiency, for example.
thats what I mean - we are not aware of any bugs in clang itself that
harm FreeBSD (on i386/amd64).
btw. there are 68 open bug reports against gcc 4.2.1 in gcc bugzilla.
Roman Divacky
> > with gcc4.{3,4,5} from ports etc. by not importing clang we can
> > maybe delay this a little but it's coming anyway.
> I am pretty much fine and happy with people experimenting with clang
> or any other compilers from ports, custom built, whatever. This is very
> different from importing some compiler into base. See below about "signal".
other compilers than our stock gcc even today.
> > > Rather, I would consider the changes to ease the use of any external
> > > compiler, from ports or whatever, bent into shape and kept up to date
> > > with system progress very important, much less controversial and more
> > > useful. Then, addicts of any kool-aid-compiler can drink their potion
> > > without starting undesired relations. Unfortunately, this is not what
> > > happen.
> >
> > this is orthogonal to this. we as a project aim for delivering complete
> > operating system and we just need a system compiler. gcc4.2.1 just
> > cant serve us anymore, we need to do something now.
> Please describe why gcc in base cannot serve us anymore while served up
> to the minute I got your message.
that was summarized in a beautiful way by Scott Long :)
Astrodog
I don't think this is really a question of "Can gcc work in base right
now?". Everyone knows it can, because that's what's actually being
used at this very moment. At the same time, I don't think there's any
real argument in saying that eventually FreeBSD will have to switch to
either a new compiler, or a new version of gcc, with the GPLv3
nightmare that could entail (Maybe that's a few years from now, I have
no idea, but it's still going to need to happen, and its not as though
switching will get easier with time.) From my perspective, there seem
to be two real questions:
First, are the two compilers mutually exclusive? (I don't believe they are.)
Second, is there a particular reason not to do this now, that will not
exist later? (I'm not that current on what's going on.. but from what
I can tell, my thought here is no, too.)
It's not as though this is irreversible. It's always possible to make
the change, realize clang won't cut it just yet, and switch back a few
hours/days/weeks/whatever later. Or, like I said earlier, if it's
possible, run both.
--- Harrison
Kostik Belousov
See, there is no objection to the idea that clang can and may eventually
displace gcc in the base. This is not the subject of the thread.
The question is whether it is beneficial for FreeBSD to import
infrastructure to ease the clang-in-base spins up to the point where
user can set one variable before the build, right now.
From what it was claimed, even without the import, users can install
whatever compiler from ports, set CC and start the build. Essentially,
the import blesses the clang and its current state as ready for wide use.
Bruce Cran
Astrodog <astr...@gmail.com> wrote:
> If I understand the build process correctly, it should be possible to
> have both compilers in base for some (presumably short) period of
> time... then just have which one you use be a configuration option,
> which should give LLVM/clang some additional exposure, without the
> obvious risks of a complete switch. It should be relatively simply to
> have "clang as a compile time option in base" then "clang as default
> with gcc as an option" then "clang only", as it proves itself out
> building the tree.
From previous messages I don't think sparc64 is currently supported by
clang very well, if at all, so I think we'll still need gcc in the base
system for some time.
--
Bruce Cran
Daniel Nebdal
(...)
> From what it was claimed, even without the import, users can install
> whatever compiler from ports, set CC and start the build. Essentially,
> the import blesses the clang and its current state as ready for wide use.
>
Not necessarily. If it is
- disabled by default
- not recommended anywhere
- recommended against for production usage (I suspect it will carry
the usual "might set your dog on fire" - disclaimer for a while)
that's hardly a glowing recommendation. I'm not sure if it's the best
comparison, but it reminds me of how SCHED_ULE was available but
mostly ignored until it was made default.
--
Daniel Nebdal
Ashley Penney
>
> See, there is no objection to the idea that clang can and may eventually
> displace gcc in the base. This is not the subject of the thread.
>
> The question is whether it is beneficial for FreeBSD to import
> infrastructure to ease the clang-in-base spins up to the point where
> user can set one variable before the build, right now.
>
> From what it was claimed, even without the import, users can install
> whatever compiler from ports, set CC and start the build. Essentially,
> the import blesses the clang and its current state as ready for wide use.
>
This import simply makes it possible to start testing clang in a more
widespread
fashion. It doesn't bless anything or make any kind of claim to the
suitability of
clang for production. I for one am excited about this import and think that
this
kind of bold step is an enormous victory for FreeBSD. Clang is clearly the
future
of compiler technology and the earlier we get on board the more involvement
we
will have with the Clang team and everyone will reap the benefits.
So, while I'm just a user this absolutely gets my vote and I look forward to
it.
Robert Watson
On Mon, 31 May 2010, Scott Long wrote:
> On May 31, 2010, at 3:56 AM, Kostik Belousov wrote:
>>
>> My personal opinion is that pushing the import now at the present state of
>> clang makes a disservice to FreeBSD, and possible clang. Why not keep the
>> glue on the branch as it is ? Motivated testers willing to help definitely
>> can checkout from the branch. Import can happen when we are satisfied with
>> the quality of new compiler, instead of discontent about old one.
>
> Who is "we", and what is their criteria? Are you speaking for the entire
> FreeBSD project?
I think Kostik's question here is legitimate: clang maturity changes over
time. The earlier we adopt it, the sooner we get the advantages of clang --
but we also end up being the people who fault in more of the hard-to-diagnose
compiler bugs. Since Kostik fields many of our complex file system/VM/etc
bugs, which are themselves often symptoms of hardware problems rather than
software bugs (a similar class of issue), and is on the release engineering
team, I think he speaks with some authority on the matter.
I happen to (currently) disagree with him on whether clang is ready for us to
drop in the base system, as I feel providing early access to it (but not
enabling it as the bootstrap by default) will be of significant benefit, but
don't think that delegitimizes the concern he raises. You can burn a lot of
hours chasing software bugs only to eventually (or never) figure out they are
compiler bugs.
This is the trade-off, but as you point out in your e-mail, there is also a
larger non-technical context. By throwing our weight behind clang, we benefit
in numerous and often non-technical ways: we lend the clang folks an engaged
and technically astute user community who can help them mature their software,
as well as give them a user they community they can point at as part of
establishing their own legitimacy. That engagement in turn means they will be
more responsive to our needs, and it's clear we're at a swing of the
compiler/systems pendulum where we can benefit from the improved compiler
technology we get through using clang.
I also have to say that I've found the clang folks extremely responsive to
date -- the one compiler bug I ran into doing the GCD port to FreeBSD was
fielded in about 60 minutes, from my report to a fix in their tree. Very
impressive. Of course, I also burned 4-6 hours realizing it was a compiler
bug before we got to that point, which is, of course, precisely the issue
Kostik is pushing on. But I think, at this moment, it's a risk we need to
take, manage it well, and benefit from the results.
Robert
Steve Kargl
>
> I'm running on a "full" ClangBSD system (world and kernel), and I've
> had no issues for the past couple of days. I've had the machine
> working nearly constantly -- building new and updating installed
> ports, running several ezjails (PostgreSQL, Apache 2.2, etc...), and
> generally using/abusing my computer by watching Flash video on the
> bsdconferences channel on YouTube...
>
> So, what exactly should we expect, if anything, to break? :)
Did you build and install new boot code? ISTR that clang
can't compile src/sys/boot/i386/boot0 to the required
512 bytes.
--
Steve
Daniel Eischen
>
> I think Kostik's question here is legitimate: clang maturity changes over
> time. The earlier we adopt it, the sooner we get the advantages of clang --
> but we also end up being the people who fault in more of the hard-to-diagnose
> compiler bugs. Since Kostik fields many of our complex file system/VM/etc
> bugs, which are themselves often symptoms of hardware problems rather than
> software bugs (a similar class of issue), and is on the release engineering
> team, I think he speaks with some authority on the matter.
>
> I happen to (currently) disagree with him on whether clang is ready for us to
> drop in the base system, as I feel providing early access to it (but not
> enabling it as the bootstrap by default) will be of significant benefit, but
> don't think that delegitimizes the concern he raises. You can burn a lot of
> hours chasing software bugs only to eventually (or never) figure out they are
> compiler bugs.
>
> This is the trade-off, but as you point out in your e-mail, there is also a
> larger non-technical context. By throwing our weight behind clang, we
> benefit in numerous and often non-technical ways: we lend the clang folks an
> engaged and technically astute user community who can help them mature their
> software, as well as give them a user they community they can point at as
> part of establishing their own legitimacy. That engagement in turn means
> they will be more responsive to our needs, and it's clear we're at a swing of
> the compiler/systems pendulum where we can benefit from the improved compiler
> technology we get through using clang.
I would like to see this decision made without political bias.
Is clangBSD able to support all our architectures? Does it
cross build for powerpc, mips, etc? Has it made a ports run
and does it successfully build and run most of our ports on
Tier-1 archs, and does it compare similarly with gcc for ports
on other archs?
If it is clearly in a state to entirely replace gcc, then
I say import it. But if it is not yet there, and won't be
for some time, then I would say leave it out for the time
and import it when it can.
--
DE
Dimitry Andric
>> So, what exactly should we expect, if anything, to break? :)
>
> Did you build and install new boot code? ISTR that clang
> can't compile src/sys/boot/i386/boot0 to the required
> 512 bytes.
No, boot0 is written in assembly, and run through the regular (GNU)
assembler. Neither gcc nor clang do anything more except calling the
linker.
The only component (in the whole clangbsd src tree) which still needs to
be compiled with gcc is boot2, which otherwise ends up just a little too
big, and doesn't fit. This is being worked on, but it isn't very
critical, really. Note that clangbsd automatically uses gcc for this
specific code, unless you override it manually.
Steve Kargl
> On 2010-05-31 16:49, Steve Kargl wrote:
> >> So, what exactly should we expect, if anything, to break? :)
> >
> > Did you build and install new boot code? ISTR that clang
> > can't compile src/sys/boot/i386/boot0 to the required
> > 512 bytes.
>
> No, boot0 is written in assembly, and run through the regular (GNU)
> assembler. Neither gcc nor clang do anything more except calling the
> linker.
>
> The only component (in the whole clangbsd src tree) which still needs to
> be compiled with gcc is boot2, which otherwise ends up just a little too
> big, and doesn't fit. This is being worked on, but it isn't very
> critical, really. Note that clangbsd automatically uses gcc for this
> specific code, unless you override it manually.
Doesn't this imply that clang/llvm isn't quite ready for deployment.
Being able to boot a complete clang/llvm compiled FreeBSD system
would seem to be critical.
When you say "This is being worked on", do you mean clang/llvm is being
changed to compile boot2 or do you mean boot2 is being changed to
allow clang/lvvm to compile it?
--
Steve
Dimitry Andric
> Doesn't this imply that clang/llvm isn't quite ready for deployment.
> Being able to boot a complete clang/llvm compiled FreeBSD system
> would seem to be critical.
You can boot it just fine, only the boot2 part is compiled with gcc, for
now. Clang can successfully compile boot2; the issue is that its
'optimize for size' option is not as good as gcc at the moment. At the
same time, boot2 is so tight on space, that it misses out by just a few
100 bytes.
> When you say "This is being worked on", do you mean clang/llvm is being
> changed to compile boot2 or do you mean boot2 is being changed to
> allow clang/lvvm to compile it?
Clang/llvm is being fixed to produce small enough code to fit into the
size limit that boot2 has (7 kiB IIRC); no ETA yet. The boot2 code
itself should not have to be modified at all (although there might be
ways to shrink that code too).
Eitan Adler
> Being able to boot a complete clang/llvm compiled FreeBSD system
> would seem to be critical.
This is why clang would be turned off by default. This import is just
making it easier to test the clangbsd branch. I'm all for this change
(and when it happens I'll start testing clangbsd).
--
Eitan Adler
Matthew Seaman
Hash: SHA1
On 31/05/2010 16:03:07, Daniel Eischen wrote:
> Is clangBSD able to support all our architectures? Does it
> cross build for powerpc, mips, etc? Has it made a ports run
> and does it successfully build and run most of our ports on
> Tier-1 archs, and does it compare similarly with gcc for ports
> on other archs?
Mostly agree, but waiting until clang can compile most of the ports is
going to be a really long wait. Lots of projects out there won't want
to support anything other than gcc for the forseable future. Presumably
the import of clang to the base does not mean the immediate removal of
gcc. Is it really such a bad thing to have gcc as a build-dependency
for various ported applications?
Cheers,
Matthew
- --
Dr Matthew J Seaman MA, D.Phil. 7 Priory Courtyard
Flat 3
PGP: http://www.infracaninophile.co.uk/pgpkey Ramsgate
JID: mat...@infracaninophile.co.uk Kent, CT11 9PW
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.14 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkwD3UsACgkQ8Mjk52CukIwCiACdGEn8qPpCoCnGN2u+E3S96BnQ
mHAAnAy74w651EtuHf7bkWtjd9WSR/Ny
=5QiA
-----END PGP SIGNATURE-----
Brandon Gooch
<s...@troutmask.apl.washington.edu> wrote:
> On Mon, May 31, 2010 at 02:49:35AM -0500, Brandon Gooch wrote:
>>
>> I'm running on a "full" ClangBSD system (world and kernel), and I've
>> had no issues for the past couple of days. I've had the machine
>> working nearly constantly -- building new and updating installed
>> ports, running several ezjails (PostgreSQL, Apache 2.2, etc...), and
>> generally using/abusing my computer by watching Flash video on the
>> bsdconferences channel on YouTube...
>>
>
> Did you build and install new boot code? ISTR that clang
> can't compile src/sys/boot/i386/boot0 to the required
> 512 bytes.
No, I didn't install new boot code. Whether or not it was built, I'll
check and see; I'm not sure exactly when/where it's built -- during
buildkernel?
This is an example of the reason I put the quotes around "full" -- I'm
not sure exactly how completely ClangBSD my system really is :)
-Brandon
Alexandre "Sunny" Kovalenko
> On Sat, May 29, 2010 at 8:02 AM, Roman Divacky <rdiv...@freebsd.org> wrote:
> > hi,
> >
> > ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import
> > as possible and therefore we ask you to test ClangBSD to assure that the revision
> > we are importing does not have some really embarassing bugs.
> >
> > How to do it (on i386 and amd64):
> >
> > 0) install fresh devel/llvm-devel port
> >
> > 1) svn co http://svn.freebsd.org/base/projects/clangbsd src
> >
> > 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf
> >
> > 3) cd src && make buildworld
> >
> > 4) make installworld DESTDIR=/usr/clangbsd
> >
> > 5) (optional) try to build kernel with clang and boot it
> >
> > 5.1) cd /sys/{arch}/conf
> > 5.2) config YOUR_KERNEL
> > 5.3) setenv CC clang in tcsh or export CC=clang in bash
> > 5.4) cd ../compile/YOUR_KERNEL
> > 5.5) make && make install
> >
> > please make sure that it builds (on amd64/i386) and that the resulting world
> > is runnable. ie. try to chroot into it and "do stuff". ie.
> >
> > chroot /clangbsd /bin/tcsh
> >
> > ... stuff ...
> >
> >
> > there's a wiki page on this effort: http://wiki.freebsd.org/BuildingFreeBSDWithClang
> >
> > please report back any problems/success to me and/or this mailing list.
> >
> > thank you for your testing!
> >
> > Roman Divacky on behalf of the ClangBSD team
> >
>
> had no issues for the past couple of days. I've had the machine
> working nearly constantly -- building new and updating installed
> ports, running several ezjails (PostgreSQL, Apache 2.2, etc...), and
> generally using/abusing my computer by watching Flash video on the
> bsdconferences channel on YouTube...
What is the good way to do installworld from CURRENT-snapshot to
ClangBSD? Half way through some shared object (run-time loader?) gets
overwritten and it is all signal 11 from there on.
Thank you in advance.
--
Alexandre Kovalenko (Олександр Коваленко)
--------------------------------------------------------------
Ovi Mail: Available in 20 languages
http://mail.ovi.com
Erik Cederstrand
Den 29/05/2010 kl. 15.02 skrev Roman Divacky:
> ClangBSD was updated to LLVM/clang revision 104832 which is what we aim to import
> into HEAD in roughly a week. We would like the initial import to be as painless
> as possible and therefore we ask you to test ClangBSD to assure that the revision
> we are importing does not have some really embarassing bugs.
I've been running the stress2 test suite on ClangBSD (in a VirtualBox VM) for the last 48 hours with no crashes. I needed to pull in a couple of patches that have been committed to FreeBSD HEAD since the last merge with ClangBSD to avoid specific crashes, but now everything seems to work just fine.
I do have a problem with buildworld on an unmodified ClangBSD src/ tree within a ClangBSD VM. Clang barfs on the mmintrin.h headers when building it's own Lexer because it picks up the gcc version of the headers instead of the clang version. This has been fixed before in ClangBSD, but probably the logic to decide on which headers to use are insufficient.
Thanks,
Erik
Alexandre "Sunny" Kovalenko
> On 2010-05-31 19:44, Alexandre "Sunny" Kovalenko wrote:
> > What is the good way to do installworld from CURRENT-snapshot to
> > ClangBSD? Half way through some shared object (run-time loader?) gets
> > overwritten and it is all signal 11 from there on.
>
>
> A fix for this has already been applied in head, but it was not yet
> merged back to clangbsd. That is going to happen soon. In the
> meantime, please:
> - Use /rescue to rollback /libexec/ld-elf.so.1 (from the backup in
> /libexec/ld-elf.so.1.old)
> - Apply the patch I have attached to your clangbsd source dir
> - Rebuild libexec/rtld-elf in there
>
> Then you should be able to do installworld without any problems.
> _______________________________________________
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-curre...@freebsd.org"
That worked perfectly, thank you!
If someone wants to host VirtualBox image of more-or-less fresh
(yesterday + patch from Dimitry) clang-built system (1.1GB), please,
contact me off the list.
--
Alexandre Kovalenko (Олександр Коваленко)
--------------------------------------------------------------
Ovi Mail: Create an account directly from your phone
Alexander Kabaev
Steve Kargl <s...@troutmask.apl.washington.edu> wrote:
> On Mon, May 31, 2010 at 05:07:44PM +0200, Dimitry Andric wrote:
> > On 2010-05-31 16:49, Steve Kargl wrote:
> > >> So, what exactly should we expect, if anything, to break? :)
> > >
> > > Did you build and install new boot code? ISTR that clang
> > > can't compile src/sys/boot/i386/boot0 to the required
> > > 512 bytes.
> >
> > No, boot0 is written in assembly, and run through the regular (GNU)
> > assembler. Neither gcc nor clang do anything more except calling
> > the linker.
> >
> > The only component (in the whole clangbsd src tree) which still
> > needs to be compiled with gcc is boot2, which otherwise ends up
> > just a little too big, and doesn't fit. This is being worked on,
> > but it isn't very critical, really. Note that clangbsd
> > automatically uses gcc for this specific code, unless you override
> > it manually.
>
> Doesn't this imply that clang/llvm isn't quite ready for deployment.
> Being able to boot a complete clang/llvm compiled FreeBSD system
> would seem to be critical.
>
> When you say "This is being worked on", do you mean clang/llvm is
> being changed to compile boot2 or do you mean boot2 is being changed
> to allow clang/lvvm to compile it?
>
FWIW, boot2 was a problem child for each and every GCC import on my
memory. Every single major GCC release has claimed better optimizations
and more compact generated code and yet they all inevitably generated
code which was appreciably bigger than code produced by previus GCC
version. This should not be used as an excuse to hold clang at bay,
provided base src still comes with working way for building the working
boot2 image (gcc).
--
Alexander Kabaev
Alexandre "Sunny" Kovalenko
> hi,
>
> into HEAD in roughly a week. We would like the initial import to be as painless
> as possible and therefore we ask you to test ClangBSD to assure that the revision
> we are importing does not have some really embarassing bugs.
>
>
> 0) install fresh devel/llvm-devel port
>
> 1) svn co http://svn.freebsd.org/base/projects/clangbsd src
>
> 2) echo NO_WERROR= >> /etc/src.conf ; echo WERROR= >> /etc/src.conf
>
> 3) cd src && make buildworld
>
> 4) make installworld DESTDIR=/usr/clangbsd
>
> 5) (optional) try to build kernel with clang and boot it
>
> 5.1) cd /sys/{arch}/conf
> 5.2) config YOUR_KERNEL
> 5.3) setenv CC clang in tcsh or export CC=clang in bash
> 5.4) cd ../compile/YOUR_KERNEL
> 5.5) make && make install
>
> please make sure that it builds (on amd64/i386) and that the resulting world
> is runnable. ie. try to chroot into it and "do stuff". ie.
>
> chroot /clangbsd /bin/tcsh
>
> ... stuff ...
>
>
> there's a wiki page on this effort: http://wiki.freebsd.org/BuildingFreeBSDWithClang
>
> please report back any problems/success to me and/or this mailing list.
>
> thank you for your testing!
>
> Roman Divacky on behalf of the ClangBSD team
Good people,
I have VirtualBox image of the ClangBSD (kernel + world i386) with the
clang installed, and Niclas generously offered to host it on his FTP
server. Image size (compressed) is slightly over 1GB.
Before we go through the hoops of moving image over, I am trying to see
whether there is sufficient interest in it. Would people, who are
interested, please, contact me off list -- if count tallies at about 10,
I will upload the image and Niclas will post URL here.
While I realize that moving target like ClangBSD, probably made this
image obsolete while I was building it, I think it will provide starting
point for those who want to test and/or experiment at the cost of
download.
Please, let me know.
--
Alexandre Kovalenko (Олександр Коваленко)
--------------------------------------------------------------
Ovi Mail: Easy setup in minutes
Garrett Cooper
Working with known deficiencies in a given system is much easier to
deal with than unknown deficiencies in a new system. I think that's
the point that several folks are trying to address. Unless there is a)
sufficient testcases to exercise each piece of functionality, and/or
b) enough soak time, you're playing a bit of a dangerous game with the
unknown.
I personally would much rather have the glue in place to switch
between compilers and have things default to the base version of gcc
than just magically switch the compiler over to clang.
But I like my bikesheds painted gray.
Thanks,
-Garrett
Tim Kientzle
> Presumably the import of clang to the base does
> not mean the immediate removal of gcc.
Of course not.
I'm not part of core and don't know what they
may have discussed, but I went through some hoops
to replace 'tar' and 'cpio' in the base system
and have some idea what approach we might take
with clang:
I would expect FreeBSD 9 to ship with both
compilers, with gcc as the default for 'cc'.
So users of 9-STABLE would see and use gcc
unless they specifically chose to use clang.
Even if we did decide to switch the default
for FreeBSD 10, it's possible we would continue
to install gcc as part of the base system
(just not as 'cc').
So realistically, some form of gcc will be built
and installed by default for a few more years.
Beyond that, it depends partly on how well clang
does and partly on how many problems we have with
an increasingly out-of-date gcc.
Cheers,
Tim
Brooks Davis
> Matthew Seaman wrote:
>> Presumably the import of clang to the base does
>> not mean the immediate removal of gcc.
>
> Of course not.
>
> I'm not part of core and don't know what they
> may have discussed, but I went through some hoops
> to replace 'tar' and 'cpio' in the base system
> and have some idea what approach we might take
> with clang:
>
> I would expect FreeBSD 9 to ship with both
> compilers, with gcc as the default for 'cc'.
> So users of 9-STABLE would see and use gcc
> unless they specifically chose to use clang.
>
> Even if we did decide to switch the default
> for FreeBSD 10, it's possible we would continue
> to install gcc as part of the base system
> (just not as 'cc').
>
> So realistically, some form of gcc will be built
> and installed by default for a few more years.
> Beyond that, it depends partly on how well clang
> does and partly on how many problems we have with
> an increasingly out-of-date gcc.
Exactly. We will need to take some risks here, but nuking gcc from the
tree won't be one of them for a while.
I just sent a link to current and arch with links to the toolchain
summit wiki page and a summary of the results. I encorage interested
parties to read what is there and provide constructive suggestions.
-- Brooks
Freddie Cash
> I personally would much rather have the glue in place to switch
> between compilers and have things default to the base version of gcc
> than just magically switch the compiler over to clang.
>
>From all the threads I've read on this subject, that's exactly what is
planned:
- import clang into the source tree
- add knobs to select which compiler to use
- leave GCC as the default compiler
IOW, unless you actually want to test clang and set the appropriate knobs,
then nothing will change for you. Everything works as per normal.
I really don't see what the big deal is, or why everyone is getting their
knickers in a knot over this.
GCC isn't being removed from the tree. GCC is staying the default compiler.
The sky is not falling.
If you want to test clang, you can. If you don't want to test clang, you
aren't forced to in any way, shape, or form.
It's really no different from the processes used when adding libthread
alongside libkse, or add sched_ule alongside sched_bsd. The defaults didn't
change, both were available, and everyone carried on without issues while
those motivated to test the new bits did so. Eventually, enough bugs were
found and fixed, things stabilised, and the new bits became the default.
Similar process here.
I may be only a lowly user and occasional tested of new bits, but I really
don't understand the mountain people are making of this ant hill.
--
Freddie Cash
fjw...@gmail.com
James R. Van Artsdalen
> Sounds like you're inviting the discussion right now. I'll start =-)
>
> 1. I hate gcc with the burning heat of a million suns. It's not a tool, it's a political weapon wielded by the FSF and their acolytes. It's also a crummy piece of software that has been "good enough" for far too long. Its development model is a burden to work with and has been a major liability towards FreeBSD releases in the past. Its demise cannot happen soon enough.
Without that "political weapon" FreeBSD would not have the rich userland
it has today. It may not be as important any more but it sure surely
was in the '80s into the early '90s.
As for the problems with gcc, you have to understand the history. I was
the x86 maintainer for a few years, yet by the time of my involvement
around 1990 the basic architecture had already been set around the
MC68000 with the question being whether Alpha, MIPS or etc would be the
future - nobody expected x86 to be viable for much longer and the goal
was "widely-retargetable" at least until things settled out. The x86
did not meet gcc's minimum processor requirements and required hacks to
work at all. Had it not been for RMS's insistence x86 might have been
deprecated.
The other key issue was how little manpower was available. There was
only one person paid to do gcc work - if you call RMS's "activist wages"
paid - and the volunteers worked out of whatever spare time they had. I
already had an 80 hour/week job *before* volunteering and I think that
was not unusual. As a result design decisions were strongly tilted in
favor of maintainability over performance. A lot of good code donations
were rejected because we simply could not afford to maintain it. I
think I accepted only one significant code donation for x86 because of
that (the 387 reg-stack code).
If someone is willing to do a clean-sheet design around the realities
and manpower of 2010 instead of 1988 that's a good thing.
I do suggest modifying the FreeBSD build process so that uname -a shows
the compiler and its version for both the kernel and userland.
Lawrence Stewart
[snip interesting history]
> I do suggest modifying the FreeBSD build process so that uname -a shows
> the compiler and its version for both the kernel and userland.
Reading through this discussion, I wanted to draw attention to this
footnote in James' email. It sounds like a sensible and useful
suggestion that would go some way to addressing Kostik's concerns about
knowing whether a kernel bug report was related to a gcc or clang built
kernel.
Cheers,
Lawrence
Doug Barton
> On 06/01/10 09:25, James R. Van Artsdalen wrote:
> [snip interesting history]
>
>> I do suggest modifying the FreeBSD build process so that uname -a shows
>> the compiler and its version for both the kernel and userland.
>
> Reading through this discussion, I wanted to draw attention to this
> footnote in James' email. It sounds like a sensible and useful
> suggestion that would go some way to addressing Kostik's concerns about
> knowing whether a kernel bug report was related to a gcc or clang built
> kernel.
+1
--
... and that's just a little bit of history repeating.
-- Propellerheads
Improve the effectiveness of your Internet presence with
a domain name makeover! http://SupersetSolutions.com/
Garrett Cooper
> On 05/31/10 17:46, Lawrence Stewart wrote:
>>
>> On 06/01/10 09:25, James R. Van Artsdalen wrote:
>> [snip interesting history]
>>
>>> I do suggest modifying the FreeBSD build process so that uname -a shows
>>> the compiler and its version for both the kernel and userland.
>>
>> Reading through this discussion, I wanted to draw attention to this
>> footnote in James' email. It sounds like a sensible and useful
>> suggestion that would go some way to addressing Kostik's concerns about
>> knowing whether a kernel bug report was related to a gcc or clang built
>> kernel.
>
> +1
I doubt there's anyone that would disagree with this. The only thing
that would be painful is if there were mixed compiles with
applications and triage, but if that was the case the user should
debug their own issue because they'd be mixing and matching toolchains
:/...
Thanks,
-Garrett
Steve Kargl
>
> On Mon, 31 May 2010 17:01:15 +0100
> Matthew Seaman <m.se...@infracaninophile.co.uk> wrote:
>
> > Is it really such a bad thing to have gcc as a build-dependency
> > for various ported applications?
>
> a few that still require gcc-3.4.6.
>
> [on my system, that's :
> ffmpeg-0.5.1_3,1
> gegl-0.1.2_1
> gimp-app-2.6.8_3,1
> ufraw-0.16_3
> x264-0.0.20100222_1
> xsane-0.996_3
> blas-1.0_4
> lapack-3.2.1_1
Well, blas and lapack require gcc-4.4.4 because these
are implemented in Fortran. Fortran was removed
from FreeBSD's base several years ago. Note, also
that clang/llvm can't compile these libraries so
the dependencies won't disappear anytime soon.
--
Steve
Robert Watson
> I personally would much rather have the glue in place to switch between
> compilers and have things default to the base version of gcc than just
> magically switch the compiler over to clang.
>
> But I like my bikesheds painted gray.
Calling that a bikeshed misses the point of bikesheds. :-)
I can't imagine that anyone is arguing for switching the default compiler to
clang any time soon. The goal of the current exercise is to provide
infrastructure and increase exposure. An entirely seperate set of decisions
will be required to (perhaps) throw the following switches:
- Make clang the default bootstrapping compiler (i.e., build kernel+world with
it) on supported architectures.
- Make clang the default ports build compiler.
- Install clang as cc.
Robert
Kostik Belousov
> On 06/01/10 09:25, James R. Van Artsdalen wrote:
> [snip interesting history]
>
> >I do suggest modifying the FreeBSD build process so that uname -a shows
> >the compiler and its version for both the kernel and userland.
>
> Reading through this discussion, I wanted to draw attention to this
> footnote in James' email. It sounds like a sensible and useful
> suggestion that would go some way to addressing Kostik's concerns about
> knowing whether a kernel bug report was related to a gcc or clang built
> kernel.
This is unsufficient. What could work is if clang provided some common
symbol into all .o files generated by it, e.g. __clang_compiled. And
then kernel considered tainted with corresponding banner printed when
weak reference to that symbol is resolved to non-zero. This does not
handle modules and does not cleanly handle usermode runtime (libc,
libthr, rtld etc).
I do not care about users busting their systems by using alternative
compilers and/or mixed builds. I worry about wasting developers time
chasing bugs that are not bugs in the FreeBSD system. As an example
see low-visible thread about sig11 during buildworld.
Andrius Morkūnas
> It would be useful to exclude clang or gcc from the build manually.
You'd either have to fix a lot of ports or install gcc from ports
anyway. Excluding gcc isn't too useful at the moment, but I see how
that could be used in the future, once ports infrastructure knows
that gcc isn't the one and only compiler.
--
Andrius
Alban Hertroys
> My main concern is the usefulness of HEAD for routine bug-fixing process.
>
> The proposed merge makes it relatively easy for users to start compiling
> the system with CLang. Our HEAD userbase is one of the most valuable
> project asset to ensure the quality of the system. After the support for
> easy compilation with clang is imported, some substantial portion of the
> HEAD users definitely start experimenting with it. This immediately makes
> the bug reports against HEAD almost useless, since level of demotivation
> when looking at the bug is immense. When you do know that the issue can
> be in the compiler, and not the OS, why looking ?
>
> Any bug analisys now shall start with exchange to verify which compiler
> was used to build the reporter system, and ask to reproduce it with gcc.
> [I am talking not only about gnats, but also mailing list questions,
> private pleas for help etc].
True enough, but that coin has two sides.
Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang, but if you have multiple compilers at your disposal you can determine that you're probably looking at a compiler bug instead of a FreeBSD bug.
Especially once there are users running the same code compiled with gcc and with clang it should be /easier/ to determine whether it's a compiler bug or not. Seeing a "Y doesn't work for me compiled with clang" vs. "Y works for me compiled with gcc" or vice versa would mean that the problem is likely in one of the compilers.
Now you're probably correct in saying that the number of compiler bugs you are likely to encounter /now/ would be higher in clang than in gcc, but there also have been a number of cases where clang found bugs in code that gcc didn't find.
Whether you find that useful is up to you, you are the developers after all.
Alban Hertroys
--
Screwing up is an excellent way to attach something to the ceiling.
!DSPAM:930,4c04de8b10155455914109!
b. f.
in this thread. I think we're all better off because of the existence
of the FSF and their affiliates, and of a body of useful software
under the (L)GPL, even if we prefer another license. No one has
forced us to use the work that they've made freely available.
With regard to importing clang now, I think that the effort needed for
switching to a new compiler will not be greatly diminished by waiting,
and we will be better served by learning about possible problems (and
attempting to have them fixed upstream) sooner rather than later.
Those who are concerned about introducing more variables into
debugging will still be free to disregard reports involving clang for
now if they choose, and we can emphasize that users should provide
information about which compiler is involved in bug reports.
Please, will those managing the import follow the recommendation of
the tool-chain summit in allowing users to opt out of building and
installing clang and any related tools with a knob in src.conf, and
add support for ripping it out via the delete-old(-libs) targets and
tools/build/mk/OptionalObsoleteFiles.inc, as part of any initial
import?
Also, others have announced that they are running regression tests on
systems built with clang. Would it be possible to set up some
regularly scheduled tests to uncover possible problems, if this hasn't
been done already?
b.
Erik Cederstrand
>
> Also, others have announced that they are running regression tests on
> systems built with clang. Would it be possible to set up some
> regularly scheduled tests to uncover possible problems, if this hasn't
> been done already?
As far as I know, regression tests in FreeBSD are pretty sporadic, and a real regression testing system is an open project (http://www.freebsd.org/projects/ideas/ideas.html#p-regression).
There's a collection of tests in src/tools/regression which can be run by installing devel/p5-Test-Harness. It does seem like the tests are in a sorry state, as an insane amount of tests are failing for me:
freebsd# uname -a
FreeBSD freebsd.local 8.0-RELEASE FreeBSD 8.0-RELEASE #0: Sat Nov 21 15:02:08 UTC 2009 ro...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
freebsd# cd /usr/src/tools/regression/
freebsd# prove fstest/tests/chflags
fstest/tests/chflags/00.t .. ok
fstest/tests/chflags/01.t .. Failed 5/5 subtests
fstest/tests/chflags/02.t .. Failed 6/6 subtests
fstest/tests/chflags/03.t .. Failed 13/13 subtests
[...]
Result: FAIL
clangbsd# uname -a
FreeBSD clangbsd.local 9.0-CURRENT FreeBSD 9.0-CURRENT #2 r208586:208611M: Thu May 27 23:35:35 CEST 2010 root@vb_fbsd8.local:/usr/obj/usr/home/erik/freebsd/clangbsd/src/sys/GENERIC amd64
clangbsd# cd /usr/src/tools/regression/
clangbsd# prove fstest/tests/chflags
fstest/tests/chflags/00.t .. ok
fstest/tests/chflags/01.t .. Failed 5/5 subtests
fstest/tests/chflags/02.t .. Failed 6/6 subtests
fstest/tests/chflags/03.t .. Failed 13/13 subtests
[...]
Result: FAIL
Thanks,
Erik
Bruce Cran
Erik Cederstrand <er...@cederstrand.dk> wrote:
> There's a collection of tests in src/tools/regression which can be
> run by installing devel/p5-Test-Harness. It does seem like the tests
> are in a sorry state, as an insane amount of tests are failing for me:
I get quite a different result on my standard 9-CURRENT system,
testing a UFS filesystem:
router# prove -r /usr/src/tools/regression/fstest/tests/chflags
/usr/src/tools/regression/fstest/tests/chflags/00.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/01.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/02.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/03.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/04.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/05.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/06.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/07.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/08.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/09.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/10.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/11.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/12.t .. ok
/usr/src/tools/regression/fstest/tests/chflags/13.t .. ok
All tests successful.
Files=14, Tests=631, 123 wallclock secs ( 1.95 usr 0.41 sys + 8.50
cusr 29.30 csys = 40.16 CPU) Result: PASS
Don't know what that proves though :P
--
Bruce Cran
Steve Kargl
>
> Compiler bugs in gcc are probably just as hard to find as
> compiler bugs in clang, but if you have multiple compilers
> at your disposal you can determine that you're probably
> looking at a compiler bug instead of a FreeBSD bug.
>
> Especially once there are users running the same code compiled
> with gcc and with clang it should be /easier/ to determine
> whether it's a compiler bug or not. Seeing a "Y doesn't work
> for me compiled with clang" vs. "Y works for me compiled with
> gcc" or vice versa would mean that the problem is likely in
> one of the compilers.
>
Apparently, you've never read a programming language
standard document. You could run into the above
situation where both compilers are behaving correctly.
Most language standards contain language of the form
"processor dependent behavior" or "implementation
defined behavior".
Here's an example from a draft of the C standard (n1256.pdf).
3.4.1
implementation-defined behavior
unspecified behavior where each implementation documents how the
choice is made
EXAMPLE: An example of implementation-defined behavior is the
propagation of the high-order bit when a signed integer is
shifted right.
--
Steve
James R. Van Artsdalen
> This is unsufficient. What could work is if clang provided some common
> symbol into all .o files generated by it, e.g. __clang_compiled. And
> then kernel considered tainted with corresponding banner printed when
> weak reference to that symbol is resolved to non-zero. This does not
> handle modules and does not cleanly handle usermode runtime (libc,
> libthr, rtld etc).
>
Would it be sufficient if send-pr were modified to test the kernel, all
loaded modules, and shared objects in /lib, /usr/lib and /usr/local/lib,
and to list all items that were _not_ marked with the default compiler &
version?
Dag-Erling Smørgrav
> I do not object to a single point in your message. On the other hand, all
> said could be labeled as distilled propaganda.
Perhaps, but...
> [...] This immediately makes the bug reports against HEAD almost
> useless, since level of demotivation when looking at the bug is
> immense. When you do know that the issue can be in the compiler, and
> not the OS, why looking ?
...so is this.
DES
--
Dag-Erling Smørgrav - d...@des.no
Dag-Erling Smørgrav
> I really would like to see CLANG more integrated with FreeBSD only
> when there are 0 or similar (well-known, already analyzed, listed
> somewhere, etc.) bugs by the compiler [...]
Does this means you're planning to remove GCC, since it has tons of
known bugs?
Svein Skogen (Listmail Account)
> Attilio Rao <att...@freebsd.org> writes:
>> I really would like to see CLANG more integrated with FreeBSD only
>> when there are 0 or similar (well-known, already analyzed, listed
>> somewhere, etc.) bugs by the compiler [...]
>
> Does this means you're planning to remove GCC, since it has tons of
> known bugs?
Sounds more like a knee-jerk reaction to removal of GCC by a ... herd of
gnus. ;)
//Svein
--
--------+-------------------+-------------------------------
/"\ |Svein Skogen | sv...@d80.iso100.no
\ / |Solberg Østli 9 | PGP Key: 0xE5E76831
X |2020 Skedsmokorset | sv...@jernhuset.no
/ \ |Norway | PGP Key: 0xCE96CE13
| | sv...@stillbilde.net
ascii | | PGP Key: 0x58CD33B6
ribbon |System Admin | svein-l...@stillbilde.net
Campaign|stillbilde.net | PGP Key: 0x22D494A4
+-------------------+-------------------------------
|msn messenger: | Mobile Phone: +47 907 03 575
|sv...@jernhuset.no | RIPE handle: SS16503-RIPE
--------+-------------------+-------------------------------
If you really are in a hurry, mail me at
svein-...@stillbilde.net
This mailbox goes directly to my cellphone and is checked
even when I'm not in front of my computer.
------------------------------------------------------------
Picture Gallery:
https://gallery.stillbilde.net/v/svein/
------------------------------------------------------------
Svein Skogen (Listmail Account)
> It's exciting that there may soon be an option other than gcc for
> FreeBSD. However I have a few questions. Is there going to be a system
> in place that will allow port maintainers to say "hey this port is now
> built successfully with Clang" or "hey this port only builds
> successfully with gcc"? Is it realistic to think that gnome and kde
> could be built with Clang/LLVM now or in the future? Do you know when
> you will be interested in being notified of arbitrary ports that wont
> build with Clang, and where should these notifications be sent?
Actually, such a system kind of already exists. It's called
"build-depends" ;)
Mark Linimon
been pointed out elsewhere.
One of the things that has been discussed w/rt compilers for a while
(not just at the devsummit) was bending our minds around separating the
concept of "base system compiler" from "default ports compiler". In
-stable branches, we must and shall not do large compiler updates. But
ports probably need a more recent compiler (of whatever flavor) just to
keep as many of them building as possible. (As upstream authors switch
to newer compilers, their ports often don't build on whatever is in our
base).
Despite my enthusiasm for the future of llvm, the reality is that even
in the medium-term there are so many ports with hardwired assumptions
that they are running on gcc (not to mention on linux on i386) that it
will never be possible to fix them all. The current paradigm is that
as ports stop building with both base gcc, unless they are switched to
depending on a newer gcc from ports, they'll be marked 'broken' and go
through the deprecation cycle.
Further, I remind people that "compile" and "run" and "run equally as
well through all code-paths" are three completely separate levels of
effort, possibly having an order of magnitude more work between each.
We're looking at a multi-year process here, and not every single port is
going to survive. But again -- not all of them currently do, anwyays.
mcl
Mark Linimon
> Compiler bugs in gcc are probably just as hard to find as compiler bugs
> in clang
There are two types of compiler bug: a) bug that produces bad code; b)
bug that makes the compiler crash.
The latter number seems kind of low right now, but that's probably
because some of them are now obscured by BROKEN tags:
http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc_bug
For comparison, bitrot that is probably due to older ports not keeping
up with compiler changes is at:
http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error
I don't have any statistic for "produces bad code".