Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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. 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Sat, May 29, 2010 at 8:02 AM, Roman Divacky rdiva...@freebsd.org 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 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
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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Importing clang/LLVM into FreeBSD HEAD
Hi, I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. So please share your support or resistance to the idea of importing clang. Roman Divacky pgpHiEeWDS1oU.pgp Description: PGP signature
Re: AES NI vs BIOS settings
On Sun, May 30, 2010 at 10:55:39PM -0700, Xin LI wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I just found that if I disable AES NI in BIOS setting, FreeBSD would be able to detect it on boot with: Features2=0x29ee3ffSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b17,DCA,SSE4.1,SSE4.2,POPCNT,AESNI However if it's set to enabled I got: Features2=0x9ee3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,b17,DCA,SSE4.1,SSE4.2,POPCNT The CPU was Xeon L5630 and motherboard is Supermicro X8STi with BIOS 1.00c. Should I consider this a BIOS issue with known workaround that I consider Disable as Enabled? :) On the only machine with AESNI-capable Core i5 I have access to thanks to Sentex Communications, AESNI bit is reported as 1 and aesni instructions do work. You could try to actually use aesni and see what is broken. I failed to find a magic bit to enable/disable AESNI in the MSRs. pgpAaPzJbjeZl.pgp Description: PGP signature
Re: Importing clang/LLVM into FreeBSD HEAD
According to Roman Divacky: So please share your support or resistance to the idea of importing clang. Full support from me (but that will not be a surprise ;-)) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SUJ and mount reporting
On 05/31/10 02:25, Bjoern A. Zeeb wrote: On Mon, 31 May 2010, Ivan Voras wrote: Shouldn't SU+J be visible in the output of mount somehow? I've just enabled it on a root file system of a machine and while tunefs and dumpfs report both soft-updates and SUJ are enabled (after reboot), the mount command only shows soft-updates. Alternative question: how to verify is it active on a live file system? (running CURRENT from a few hours ago, kernelworld synced) As previously stated - this is a hack to do what I think you are asking for: http://people.freebsd.org/~bz/20100309-03-mount.diff Yes, this looks like it... Using tunefs, etc. for now would be better. I did use tunefs, as I've said, but I'm concerned what would happen (if it can - stale kernel?) if the superblock that tunefs reads from the disk and the kernel state are different. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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. 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 I do not object to a single point in your message. On the other hand, all 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. pgpYeQEsehxau.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:56:17PM +0300, Kostik Belousov wrote:
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.
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
I do not object to a single point in your message. On the other hand, all
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].
agreed. what do you propose to help identify/prevent situations when
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
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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? Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SUJ and mount reporting
On May 31, 2010, at 3:08 AM, Ivan Voras wrote: On 05/31/10 02:25, Bjoern A. Zeeb wrote: On Mon, 31 May 2010, Ivan Voras wrote: Shouldn't SU+J be visible in the output of mount somehow? I've just enabled it on a root file system of a machine and while tunefs and dumpfs report both soft-updates and SUJ are enabled (after reboot), the mount command only shows soft-updates. Alternative question: how to verify is it active on a live file system? (running CURRENT from a few hours ago, kernelworld synced) As previously stated - this is a hack to do what I think you are asking for: http://people.freebsd.org/~bz/20100309-03-mount.diff Yes, this looks like it... Using tunefs, etc. for now would be better. I did use tunefs, as I've said, but I'm concerned what would happen (if it can - stale kernel?) if the superblock that tunefs reads from the disk and the kernel state are different. MNT_* flags need to be deprecated, and the attributes passed in both directions as key-value pairs. I don't know if anyone else has thought about this and what it means for backwards compatibility. Scott ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:24:52PM +0200, Roman Divacky wrote:
On Mon, May 31, 2010 at 12:56:17PM +0300, Kostik Belousov wrote:
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.
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
I do not object to a single point in your message. On the other hand, all
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].
agreed. what do you propose to help identify/prevent situations when
people are reporting bugs coming from a compiler problem rather than
those from a genuine src problem?
If I have a good idea how to help a situation, I would described it. It
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
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
2010/5/31 Kostik Belousov kostik...@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. 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 I do not object to a single point in your message. On the other hand, all 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. 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 ___ freebsd-current@freebsd.org mailing list
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 12:54:29PM +0200, Attilio Rao wrote: 2010/5/31 Kostik Belousov kostik...@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. 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 I do not object to a single point in your message. On the other hand, all 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. 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? there are no known clang bugs (at
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
2010/5/31 Roman Divacky rdiva...@freebsd.org: On Mon, May 31, 2010 at 12:54:29PM +0200, Attilio Rao wrote: 2010/5/31 Kostik Belousov kostik...@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. 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 I do not object to a single point in your message. On the other hand, all 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. 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
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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. 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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 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. pgpCXTd7oxwJa.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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.
what I wanted to say is that we can get problem reports from people using
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 :)
pgpH7p7tmULGb.pgp
Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 6:39 AM, Roman Divacky rdiva...@freebsd.org wrote:
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.
what I wanted to say is that we can get problem reports from people using
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 :)
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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 06:55:17AM -0500, Astrodog wrote:
On Mon, May 31, 2010 at 6:39 AM, Roman Divacky rdiva...@freebsd.org wrote:
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.
what I wanted to say is that we can get problem reports from people using
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 :)
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.
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.
pgptyaKjynMra.pgp
Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010 06:11:32 -0500 Astrodog astro...@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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 2:04 PM, Kostik Belousov kostik...@gmail.com wrote: (...) 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 8:04 AM, Kostik Belousov kostik...@gmail.comwrote: 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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
on 29/05/2010 10:47 Andrew Reilly said the following: Just to prefix with my config: FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #7: Sat May 29 11:20:54 EST 2010 r...@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64 Current source tree was csupped about half an hour ago. I don't think that my hardware has gone dodgy: everything else seems to be working properly. cc itself seems to work OK when compiling my own code, too. But make buildworld -- /nb/src/cddl/usr.bin/sgsmsg/../../../sys/cddl/contrib/opensolaris/common/avl/avl.c:128: internal compiler error: Bus error: 10 Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. *** Error code 1 Stop in /nb/src/cddl/usr.bin/sgsmsg. Also, if I run buildworld with -j4 (my usual config), then a different compile crashes the same way : /nb/src/cddl/usr.bin/sgsmsg/../../../cddl/contrib/opensolaris/cmd/sgs/tools/common/string_table.c:467: internal compiler error: Bus error: 10 but in that case it was not the first compile which broke, and several (parallel, I assume) broke at the same time. So: is anyone else seeing this? Is it likely that heisenbugs have found their way into the compiler in the last week, or perhaps in the kernel's page table handling code? Have you been playing with clang or other alternative compilers? If not, then I think that it's your hardware. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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... 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 3:59 AM, Ollivier Robert robe...@keltia.freenix.fr wrote: According to Roman Divacky: So please share your support or resistance to the idea of importing clang. Full support from me (but that will not be a surprise ;-)) -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- robe...@keltia.freenix.fr In memoriam to Ondine : http://ondine.keltia.net/ I will immediately begin testing clang as soon as it is imported in HEAD. Thanks for everyone's hard work, -- Chris Ruiz - http://twitter.com/chrisattack http://chrisattack.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 09:52:48AM +0200, Roman Divacky wrote: Hi, I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. Can clang/LLVM build the livefs and bootonly CD's? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010, Robert Watson wrote: 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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? -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 07:57:49AM -0700, Steve Kargl wrote: On Mon, May 31, 2010 at 09:52:48AM +0200, Roman Divacky wrote: Hi, I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. Can clang/LLVM build the livefs and bootonly CD's? well.. it can build a slightly modified FreeBSD. I have no idea whats the difference between plain FreeBSD world and livefs and bootonly CD the modifications to the FreeBSD are mostly bug fixes that clang reveals. pgp8R2yNoCeKq.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 2010-05-31 17:18, Steve Kargl wrote: 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). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On 5/31/2010 3:52 AM, Roman Divacky wrote: Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. What about the thousands of ports? Also, have there been any tests done to compare the performance of the compiled binaries vs gcc? Thanks. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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. 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
-BEGIN PGP SIGNED MESSAGE- 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: matt...@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- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, 31 May 2010 09:52:48 +0200 Roman Divacky rdiva...@freebsd.org wrote: I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. So please share your support or resistance to the idea of importing clang. Roman Divacky I already use clang for some things but I think the issue here is not support/resistance but something else: * IMHO for a change of this nature the core needs to publish a set of clear acceptance criteria for importing clang. Can this be done? * Since clang doesn't support all the archs, what is the plan for unsupported archs? a. Is FreeBSD going to have both compilers in the base? b. Is the project drop these FreeBSD ports? or c. Do people have to import gcc from ports to build these FreeBSD ports? * What about ports? * Basically the core needs to lay out a roadmap. It is clear that not everyone has the same view of what the acceptance criteria might be so publishing it would help people understand what to expect. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 09:14:09AM -0700, Bakul Shah wrote: On Mon, 31 May 2010 09:52:48 +0200 Roman Divacky rdiva...@freebsd.org wrote: I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. So please share your support or resistance to the idea of importing clang. Roman Divacky I already use clang for some things but I think the issue here is not support/resistance but something else: * IMHO for a change of this nature the core needs to publish a set of clear acceptance criteria for importing clang. Can this be done? I asked core@ and they support the import * Since clang doesn't support all the archs, what is the plan for unsupported archs? a. Is FreeBSD going to have both compilers in the base? yes, this is what this import is about - importing clang, nothing else changes b. Is the project drop these FreeBSD ports? or no, of course not c. Do people have to import gcc from ports to build these FreeBSD ports? nothing is being changed, just one more application after a buildworld/installworld appears (that being clang) * What about ports? * Basically the core needs to lay out a roadmap. It is clear that not everyone has the same view of what the acceptance criteria might be so publishing it would help people understand what to expect. nothing changes for the ports, there's an ongoing project to enable ports to be usable with clang (or some other compiler) but thats orthogonal to this. pgp3eugjwYjdB.pgp Description: PGP signature
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, 31 May 2010 18:53:18 +0300, Mike Jakubik mike.jaku...@intertainservices.com wrote: What about the thousands of ports? Also, have there been any tests done to compare the performance of the compiled binaries vs gcc? This import is in no way directly related to ports. Somehow people have this weird idea that clang is replacing gcc, it isn't. For now ports will be compiled with gcc just like they were before. There are people working on getting ports to compile with clang, but that's a different project[1][2], and in my opinion, is somewhat offtopic for the current discussion. As for performance, I'm not sure. I wouldn't expect clang compiled binaries to be significantly faster/slower than gcc ones. [1] http://wiki.freebsd.org/PortsAndClang [2] http://wiki.freebsd.org/SOC2010AndriusMorkunas -- Andrius ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 9:49 AM, Steve Kargl 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... 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, 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 8:53 AM, Mike Jakubik mike.jaku...@intertainservices.com wrote: On 5/31/2010 3:52 AM, Roman Divacky wrote: Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. What about the thousands of ports? Also, have there been any tests done to compare the performance of the compiled binaries vs gcc? What about the ports? Lots of ports already have dependencies on GCC from ports as they don't build/run properly with GCC 4.2.1. How is this any different? There have been reports on other lists from people using Clang to build their ports, with very few failures. It's a simple matter to add a dependency on GCC from ports for those that do fail. Which is already being done for ports that don't work with GCC 4.2.1. Several -exp runs have already been done on the ports tree using Clang. No idea about benchmarks. -- Freddie Cash fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 2010-05-31 at 02:49 -0500, Brandon Gooch wrote:
On Sat, May 29, 2010 at 8:02 AM, Roman Divacky rdiva...@freebsd.org 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 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
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...
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
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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.
Hi Alexandre,
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.
Index: libexec/rtld-elf/arm/reloc.c
===
--- libexec/rtld-elf/arm/reloc.c(revision 208620)
+++ libexec/rtld-elf/arm/reloc.c(working copy)
@@ -245,7 +245,6 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
const Elf_Rel *rellim;
const Elf_Rel *rel;
SymCache *cache;
- int bytes = obj-nchains * sizeof(SymCache);
int r = -1;
/* The relocation for the dynamic loader has already been done. */
@@ -255,10 +254,9 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
* The dynamic loader may be called from a thread, we have
* limited amounts of stack available so we cannot use alloca().
*/
- cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0);
- if (cache == MAP_FAILED)
- cache = NULL;
-
+ cache = calloc(obj-nchains, sizeof(SymCache));
+ /* No need to check for NULL here */
+
rellim = (const Elf_Rel *)((caddr_t)obj-rel + obj-relsize);
for (rel = obj-rel; rel rellim; rel++) {
if (reloc_nonplt_object(obj, rel, cache) 0)
@@ -266,9 +264,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
}
r = 0;
done:
- if (cache) {
- munmap(cache, bytes);
- }
+ if (cache != NULL)
+ free(cache);
return (r);
}
Index: libexec/rtld-elf/powerpc/reloc.c
===
--- libexec/rtld-elf/powerpc/reloc.c(revision 208620)
+++ libexec/rtld-elf/powerpc/reloc.c(working copy)
@@ -287,7 +287,6 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
const Elf_Rela *relalim;
const Elf_Rela *rela;
SymCache *cache;
- int bytes = obj-nchains * sizeof(SymCache);
int r = -1;
/*
@@ -295,10 +294,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
* limited amounts of stack available so we cannot use alloca().
*/
if (obj != obj_rtld) {
- cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON,
- -1, 0);
- if (cache == MAP_FAILED)
- cache = NULL;
+ cache = calloc(obj-nchains, sizeof(SymCache));
+ /* No need to check for NULL here */
} else
cache = NULL;
@@ -314,9 +311,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
}
r = 0;
done:
- if (cache) {
- munmap(cache, bytes);
- }
+ if (cache != NULL)
+ free(cache);
return (r);
}
Index: libexec/rtld-elf/sparc64/reloc.c
===
--- libexec/rtld-elf/sparc64/reloc.c(revision 208620)
+++ libexec/rtld-elf/sparc64/reloc.c(working copy)
@@ -254,7 +254,6 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
const Elf_Rela *relalim;
const Elf_Rela *rela;
SymCache *cache;
- int bytes = obj-nchains * sizeof(SymCache);
int r = -1;
/*
@@ -262,10 +261,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
* limited amounts of stack available so we cannot use alloca().
*/
if (obj != obj_rtld) {
- cache = mmap(NULL, bytes, PROT_READ|PROT_WRITE, MAP_ANON,
- -1, 0);
- if (cache == MAP_FAILED)
- cache = NULL;
+ cache = calloc(obj-nchains, sizeof(SymCache));
+ /* No need to check for NULL here */
} else
cache = NULL;
@@ -276,8 +273,8 @@ reloc_non_plt(Obj_Entry *obj, Obj_Entry *obj_rtld)
}
r = 0;
done:
- if (cache)
- munmap(cache, bytes);
+ if (cache != NULL)
+ free(cache);
return (r);
}
Index: libexec/rtld-elf/rtld.c
===
--- libexec/rtld-elf/rtld.c (revision 208620)
+++ libexec/rtld-elf/rtld.c (working copy)
@@ -3311,6 +3311,10 @@ allocate_module_tls(int index)
}
p = malloc(obj-tlssize);
+if (p == NULL) {
+ _rtld_error(Cannot allocate TLS block for index %d, index);
+ die();
+}
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 2:52 AM, Roman Divacky rdiva...@freebsd.org wrote: Hi, I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. So please share your support or resistance to the idea of importing clang. Roman Divacky Another user YES vote here; I will begin using clang on all of my FreeBSD HEAD machines after the import. Exciting! -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
In message: 20100531161713.ga60...@freebsd.org Roman Divacky rdiva...@freebsd.org writes: : On Mon, May 31, 2010 at 09:14:09AM -0700, Bakul Shah wrote: : On Mon, 31 May 2010 09:52:48 +0200 Roman Divacky rdiva...@freebsd.org wrote: : : I would like to propose to integrate clang/LLVM into FreeBSD HEAD : in the near future (days, not weeks). : : clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly : replace gcc. It is BSDL-like licensed. The sources are ~45MB (the : svn checkout is 97MB). Clang/LLVM is written in C++. : : Clang can compile all of FreeBSD on i386/amd64 including world and booting : kernel. Other architectures that are close to working are MIPS, PowerPC : and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM : sources and the build infrastructure and this is what we aim to integrate : at first. : : The import of clang/LLVM was discussed at the toolchain summit May 10th : but I would like to hear your opinion. I got approval from core@ on : importing it. : : So please share your support or resistance to the idea of importing clang. : : Roman Divacky : : I already use clang for some things but I think the issue : here is not support/resistance but something else: : : * IMHO for a change of this nature the core needs to publish :a set of clear acceptance criteria for importing clang. :Can this be done? : : I asked core@ and they support the import They support the import, in the context of the larger plan, which you've not articulated. Let's be clear here. : * Since clang doesn't support all the archs, what is the plan :for unsupported archs? :a. Is FreeBSD going to have both compilers in the base? : : yes, this is what this import is about - importing clang, : nothing else changes There's more context here too. To improve the support of various architectures, we're planning on doing two things. First, we're updating binutils to the latest gplv2 version. This will solve many problems. There's some other plans in this area as well, but the summary is basically integrating some important vendor patches. Second, we're planning to have the ability to use an external, perhaps vendor supplied, tool chain. You can kludge this together today, but it is tedious and difficult. :b. Is the project drop these FreeBSD ports? or : : no, of course not : :c. Do people have to import gcc from ports to build these : FreeBSD ports? : : nothing is being changed, just one more application after : a buildworld/installworld appears (that being clang) : : * What about ports? The plan that was articulated at the toolchain summit was to install clang as clang, and gcc as cc, so that /usr/ports continue to work. There's a lot of work needed to make all the ports work with clang. There's a summer of code project to make it possible to select a default compiler to built ports. There's a missing piece of functionality that was agreed to in the clang tree right now. There needs to be support for 'WITH_CLANG_BOOTSTRAP' to build the system with the clang, but leave gcc as the default compiler for ports. There also needs to be support for WITH_CLANG_IS_CC which would also make clang the default. : * Basically the core needs to lay out a roadmap. There was supposed to be a summary of the roadmap posted, but that's not yet happened... Roman really should have waited to push ahead until this was posted because it does answer the bigger picture questions. : It is clear that not everyone has the same view of what the : acceptance criteria might be so publishing it would help : people understand what to expect. : : nothing changes for the ports, there's an ongoing project to enable : ports to be usable with clang (or some other compiler) but thats : orthogonal to this. Part of the problem with this thread is that the whole, agreed plan wasn't laid out at the first part of it, so people are freaking out about what the plans are for the future. They were discussed and first order agreement was reached at the tool chains summit. But part of the agreement was to post the whole agreement so people know and understand the various trade offs. I think that would go a long way towards answering the questions that are being raised and to quell the visceral reaction that I've seen in this thread Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, 31 May 2010 12:33:18 MDT M. Warner Losh i...@bsdimp.com wrote: : It is clear that not everyone has the same view of what the : acceptance criteria might be so publishing it would help : people understand what to expect. : : nothing changes for the ports, there's an ongoing project to enable : ports to be usable with clang (or some other compiler) but thats : orthogonal to this. Part of the problem with this thread is that the whole, agreed plan wasn't laid out at the first part of it, so people are freaking out about what the plans are for the future. They were discussed and first order agreement was reached at the tool chains summit. But part of the agreement was to post the whole agreement so people know and understand the various trade offs. I think that would go a long way towards answering the questions that are being raised and to quell the visceral reaction that I've seen in this thread Exactly! I still urge core to lay out a clear plan. And don't forget to indicate the acceptance criteria to be met for each step! [Not to add bureaucracy but to ensure that nothing falls through the cracks] Can't speak for others but I am very appreciative of all the work put in enthusiastically by Roman and others to get clang into FreeBSD. Exciting to have a real alternative to gcc! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 9:17 AM, Roman Divacky rdiva...@freebsd.org wrote: On Mon, May 31, 2010 at 09:14:09AM -0700, Bakul Shah wrote: On Mon, 31 May 2010 09:52:48 +0200 Roman Divacky rdiva...@freebsd.org wrote: I would like to propose to integrate clang/LLVM into FreeBSD HEAD in the near future (days, not weeks). clang/LLVM is a C/C++/ObjC compiler (framework) which aims to possibly replace gcc. It is BSDL-like licensed. The sources are ~45MB (the svn checkout is 97MB). Clang/LLVM is written in C++. Clang can compile all of FreeBSD on i386/amd64 including world and booting kernel. Other architectures that are close to working are MIPS, PowerPC and ARM. We have a branch (clangbsd-import) that just includes clang/LLVM sources and the build infrastructure and this is what we aim to integrate at first. The import of clang/LLVM was discussed at the toolchain summit May 10th but I would like to hear your opinion. I got approval from core@ on importing it. So please share your support or resistance to the idea of importing clang. Roman Divacky I already use clang for some things but I think the issue here is not support/resistance but something else: * IMHO for a change of this nature the core needs to publish a set of clear acceptance criteria for importing clang. Can this be done? I asked core@ and they support the import * Since clang doesn't support all the archs, what is the plan for unsupported archs? a. Is FreeBSD going to have both compilers in the base? yes, this is what this import is about - importing clang, nothing else changes b. Is the project drop these FreeBSD ports? or no, of course not c. Do people have to import gcc from ports to build these FreeBSD ports? nothing is being changed, just one more application after a buildworld/installworld appears (that being clang) How much time (with -j1, approximately) does it take to build clang? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 11:33 AM, M. Warner Losh i...@bsdimp.com wrote: In message: 20100531161713.ga60...@freebsd.org [...] There's more context here too. To improve the support of various architectures, we're planning on doing two things. First, we're updating binutils to the latest gplv2 version. This will solve many problems. There's some other plans in this area as well, but the summary is basically integrating some important vendor patches. Second, we're planning to have the ability to use an external, perhaps vendor supplied, tool chain. You can kludge this together today, but it is tedious and difficult. This in and of itself is an interesting prospect. Why would happen if one could drop in icc for instance :) (I realize that it's basically gcc-compatible, but can this be done today without a lot of rework and effort)? : b. Is the project drop these FreeBSD ports? or [...] Part of the problem with this thread is that the whole, agreed plan wasn't laid out at the first part of it, so people are freaking out about what the plans are for the future. They were discussed and first order agreement was reached at the tool chains summit. But part of the agreement was to post the whole agreement so people know and understand the various trade offs. I think that would go a long way towards answering the questions that are being raised and to quell the visceral reaction that I've seen in this thread +1 Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, 31 May 2010 12:35:33 -0700 Garrett Cooper yanef...@gmail.com wrote: This in and of itself is an interesting prospect. Why would happen if one could drop in icc for instance :) (I realize that it's basically gcc-compatible, but can this be done today without a lot of rework and effort)? It used to possible, but people who did the work to support ICC dropped any support for their work the minute changes hit the tree and now it is impossible to say how far exactly it has rotten. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 2010-05-31 at 20:10 +0200, Dimitry Andric wrote: 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. Hi Alexandre, 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-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@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 http://mail.ovi.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010 08:18:42 -0700 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 signature.asc Description: PGP signature
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, May 31, 2010 at 3:13 PM, Bakul Shah ba...@bitblocks.com wrote: On Mon, 31 May 2010 12:33:18 MDT M. Warner Losh i...@bsdimp.com wrote: ... Can't speak for others but I am very appreciative of all the work put in enthusiastically by Roman and others to get clang into FreeBSD. Exciting to have a real alternative to gcc! In software engineering , there is a concept : Formal Technical Reviews . In my opinion , one of the best reviewers of a software is a compiler of its language . Having a second compiler in FreeBSD , will make it much better than the present state . My wish would be to pursue a language intersection of both CLang and GCC compilers to be able to check their outputs . If I could have sufficient power ( health , time , etc. ) , I even want to try and make applicable one more compiler such as Portable C Compiler ( which is available in ports ) . Personally I am using two compilers ( Free Pascal and Delphi ) on a big program , and I am obtaining very good results either as very useful warnings or errors . In reality , to pursue such a multiple compiler usage is really difficult , but end result is making efforts very fruitful . I am using a similar technique for my Fortran programs . I can say that to rely on a single compiler is not a very robust way of software development after seeing quality of compiled programs : My policy is now Never use a single compiler without assuring that it is generating correct code when compared to other compilers even though the current compiler is tested on its test base . This is a result of so many combinations of a language usage that a test base can not cover but it may exist in a user program over time . This policy is developed by actual experiences . From these view points , workers on Clang adoption are making really a big contribution to the FreeBSD project and to its users . Thank you very much . Mehmet Erol Sanliturk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Sat, 2010-05-29 at 15:02 +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 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
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
http://mail.ovi.com
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 4:34 AM, Roman Divacky rdiva...@freebsd.org wrote: 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 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. 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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. Cheers, Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
BSDCan Toolchain Summit Summary
Before the developers summit at BSDCan a small group of developers and industry partners held a summit on toolchain issues. The agenda along with a number of slide sets appears on the wiki at: http://wiki.freebsd.org/201005ToolchainSummit The primary focus of the summit was our increasingly obsolete toolchain and how to move forward in light of the fact that GPLv3 is unacceptable to a significant portion of the FreeBSD community. Summaries of the sessions can be found at: http://wiki.freebsd.org/201005ToolchainSummitSummary This includes a rough draft of a roadmap. We need to convert this into a roadmap page with each required feature listed along with status and contacts. I encourage people to comment on the proposed roadmap and contribute to insuring the consensus matches the communities' needs as much as possible. With out question this endeavor is going to take effort on our part and involves some risk but if everyone works on it I think we can get through without too much pain. -- Brooks pgpUVvgwp9Gk5.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 03:52:27PM -0700, Tim Kientzle wrote: 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 pgpNPnYqRDglF.pgp Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 3:44 PM, Garrett Cooper yanef...@gmail.com wrote: 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 fjwc...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
Scott Long wrote: 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. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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. Cheers, Lawrence ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
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 -- ... 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/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, May 31, 2010 at 7:51 PM, Doug Barton do...@freebsd.org wrote: 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
On Mon, 31 May 2010 16:30:04 +0300
Andriy Gapon a...@icyb.net.ua wrote:
Have you been playing with clang or other alternative compilers?
I have them all installed, but none are used by the build
process. My make.conf is relatively clean.
If not, then I think that it's your hardware.
I did too at first. Compiler crashes are usually fix the
hardware problems. I'm not so sure any more: I restored /boot
and /usr/{not local or home} from backup from about a week ago,
and using that compiler on the same hardware, I was able to get a
build and install to complete without problem. Heisenbug
somewhere, perhaps? The other hit against the hardware problem
suggestion is that the failure was in specific, repeatable places
in certain system source files. I could compile a chunk of my
own code without problems, though.
I'm now on:
FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon May 31
02:39:59 EST 2010 r...@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64
based on a csup from the australian mirror from yesterday morning
(or perhaps Sunday night), and it all seems to be back to normal.
Very odd.
Cheers,
--
Andrew
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
On Mon, May 31, 2010 at 9:06 PM, Andrew Reilly arei...@bigpond.net.au wrote:
On Mon, 31 May 2010 16:30:04 +0300
Andriy Gapon a...@icyb.net.ua wrote:
Have you been playing with clang or other alternative compilers?
I have them all installed, but none are used by the build
process. My make.conf is relatively clean.
What _is_ your make.conf though?
If not, then I think that it's your hardware.
I did too at first. Compiler crashes are usually fix the
hardware problems. I'm not so sure any more: I restored /boot
and /usr/{not local or home} from backup from about a week ago,
and using that compiler on the same hardware, I was able to get a
build and install to complete without problem. Heisenbug
somewhere, perhaps? The other hit against the hardware problem
suggestion is that the failure was in specific, repeatable places
in certain system source files. I could compile a chunk of my
own code without problems, though.
I'm now on:
FreeBSD duncan.reilly.home 9.0-CURRENT FreeBSD 9.0-CURRENT #0: Mon May 31
02:39:59 EST 2010 r...@duncan.reilly.home:/nb/obj/nb/src/sys/DUNCAN amd64
based on a csup from the australian mirror from yesterday morning
(or perhaps Sunday night), and it all seems to be back to normal.
Thanks,
-Garrett
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
On Mon, 31 May 2010 21:17:41 -0700 Garrett Cooper yanef...@gmail.com wrote: What _is_ your make.conf though? Just this: #CC=clang CFLAGS+=-g CXXFLAGS+=-g KERNCONF=DUNCAN NO_LPR=YES NO_SENDMAIL=YES WITH_GTK2=yes WITH_CUPS=yes WITH_GECKO=libxul #WITH_DEBUG=yes A4=yes QT4_OPTIONS=CUPS NAS QGTKSTYLE PORTSDIR=/nb/ports PORTSSUPFILE=/root/ports-supfile SUPFILE=/root/standard-supfile SUPHOST=cvs.au.freebsd.org SUP_UPDATE=yes SUP=cvsup # OOo needs a really large TMPDIR, use this for OOo: TMPDIR=/nb/tmp/ # added by use.perl 2010-05-15 17:53:15 PERL_VERSION=5.10.1 my DUNCAN kern conf is just: include GENERIC ident DUNCAN It used to have more frobs in it than that! Just in case it matters: the kernel/userland/cc that was giving me grief had been built with a make.conf that said NO_KERBEROS=yes, something I'd added to try to work around the MD2_foo crypto linking problems. I can't imagine why that would be a problem, but I'm not risking it any more... Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
On Mon, May 31, 2010 at 9:28 PM, Andrew Reilly arei...@bigpond.net.au wrote: On Mon, 31 May 2010 21:17:41 -0700 Garrett Cooper yanef...@gmail.com wrote: What _is_ your make.conf though? Just this: #CC=clang CFLAGS+=-g CXXFLAGS+=-g KERNCONF=DUNCAN NO_LPR=YES NO_SENDMAIL=YES WITH_GTK2=yes WITH_CUPS=yes WITH_GECKO=libxul #WITH_DEBUG=yes A4=yes QT4_OPTIONS=CUPS NAS QGTKSTYLE PORTSDIR=/nb/ports PORTSSUPFILE=/root/ports-supfile SUPFILE=/root/standard-supfile SUPHOST=cvs.au.freebsd.org SUP_UPDATE=yes SUP=cvsup # OOo needs a really large TMPDIR, use this for OOo: TMPDIR=/nb/tmp/ # added by use.perl 2010-05-15 17:53:15 PERL_VERSION=5.10.1 my DUNCAN kern conf is just: include GENERIC ident DUNCAN It used to have more frobs in it than that! Just in case it matters: the kernel/userland/cc that was giving me grief had been built with a make.conf that said NO_KERBEROS=yes, something I'd added to try to work around the MD2_foo crypto linking problems. I can't imagine why that would be a problem, but I'm not risking it any more... Ok... there appear to be some interesting bits here, but I'm curious... when was the last time that you did a build with clang, and did you properly clean out /usr/obj, etc since your last compile? Thanks, -Garrett ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, 31 May 2010 17:01:15 +0100 Matthew Seaman m.sea...@infracaninophile.co.uk wrote: Is it really such a bad thing to have gcc as a build-dependency for various ported applications? There are already ports that have gcc-4.4.4 as a dependency, and 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 py26-numpy-1.4.1,1 totem-2.30.1 vinagre-2.30.1 vino-2.28.2 and ...hmm... maybe I've already de-installed whatever was depending on 3.4.6...] Anyway, I don't see this trend slowing down any time soon, so I don't think that being able to compile all of ports is a reasonable constraint on bringing clang into the tree. I've changed my mind about bringing things into the tree since my last post on the subject. Being in-tree helps a lot with the ability to cross-build, which matters now that reasonably priced beasty machines are so much faster than reasonably-priced puny machines. Also, I've learned to love tmux... Also, the ability to have NO_LLVM in make.conf should (just like the other, similar switches) answer the rebuild-time issue. Just a few cents from the peanut gallery. FWIW I'm in favour, but I do understand Kostik's concern. I've been bitten by my share of compiler bugs and hardware bugs. Perhaps, even for a while after introduction, there should be a rule like don't report a bug unless you've reproduced it on a system built with cc(=gcc), just to keep those two issues separate. Perhaps with a side order of: any bug that you find in a clang-compiled system that goes away when re-built with gcc should be reported to the clang folk... Cheers, - -- Andrew -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkwEklYACgkQgzZZe5eEKMIf4ACffE00q3RsyElRE64q3tOFovI8 Dh0An2tQLYwVc74tvXJD72bbsul0j68V =oTaO -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Yoics! Just upgraded and cc is (mostly) bus-error-ing on buildworld.
Hi Garrett, On Mon, 31 May 2010 21:36:23 -0700 Garrett Cooper yanef...@gmail.com wrote: Ok... there appear to be some interesting bits here, but I'm curious... when was the last time that you did a build with clang, and did you properly clean out /usr/obj, etc since your last compile? I don't think that I ever have (compiled with clang). I did pull the pieces together when Roman first suggested it, but it didn't work then, and I need this machine to be more up than down, so I've shelved it for a while. At that time clang also had a bug that was a show-stopper for me, in that it wouldn't compile my own code (compile time constant expressions with conditionals were not recognised as constant, or something like that.) Long since fixed, but I don't have enough time to keep up. I do regularly nuke /usr/obj before rebuilding. Not always, but often. Cheers, -- Andrew ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Tue, Jun 01, 2010 at 02:53:22PM +1000, Andrew Reilly wrote: On Mon, 31 May 2010 17:01:15 +0100 Matthew Seaman m.sea...@infracaninophile.co.uk wrote: Is it really such a bad thing to have gcc as a build-dependency for various ported applications? There are already ports that have gcc-4.4.4 as a dependency, and 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Importing clang/LLVM into FreeBSD HEAD
In message: aanlktikx-vnfgzuvh4-cevikdjslqqjrahjevdqd-...@mail.gmail.com Garrett Cooper yanef...@gmail.com writes: : On Mon, May 31, 2010 at 11:33 AM, M. Warner Losh i...@bsdimp.com wrote: : In message: 20100531161713.ga60...@freebsd.org : : [...] : : There's more context here too. To improve the support of various : architectures, we're planning on doing two things. First, we're : updating binutils to the latest gplv2 version. This will solve many : problems. There's some other plans in this area as well, but the : summary is basically integrating some important vendor patches. : Second, we're planning to have the ability to use an external, perhaps : vendor supplied, tool chain. You can kludge this together today, but : it is tedious and difficult. : : This in and of itself is an interesting prospect. Why would happen if : one could drop in icc for instance :) (I realize that it's basically : gcc-compatible, but can this be done today without a lot of rework and : effort)? This is more about dropping in different assemblers, linkers, etc, than picking icc. CC=xxx is relatively easy. It gets harder if you don't want to use the in-tree toolchain. Especially when cross building... Warner ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
