headers
Joerg Sonnenberger | 3 Feb 2011 02:08
Picon

Initial LLVM/clang patch

Hi all,
attached patch + tarball contain enough magic to get a working clang for
AMD64. I could like to get this into the tree to make it simpler to test
and integrated the changes required for doing a (almost) full world
build. Things like support for !x86 targets in clang etc can be provided
incrementally as well.

At the moment, I do not plan to import the upstream LLVM or clang
sources. src/external/llvm/Makefile has a checkout target using svn to
get the "proven" revision as specified in Makefile.inc. This avoids
having to deal with regular imports and repo churn associated.

Status is that with a bunch of other patches and some smaller hacks,
the AMD64 release build finishes almost. The GCC libraries and bootxx
are the primary issues.

Joerg
Attachment (clang-base.diff): text/x-diff, 5785 bytes
Attachment (clang-base.tar.gz): application/octet-stream, 20 KiB
Permalink | Reply | 14 comments |
headers
Alistair Crooks | 3 Feb 2011 16:39

Re: Initial LLVM/clang patch

Hi Joerg,

On Thu, Feb 03, 2011 at 02:08:30AM +0100, Joerg Sonnenberger wrote:
> attached patch + tarball contain enough magic to get a working clang for
> AMD64. I could like to get this into the tree to make it simpler to test
> and integrated the changes required for doing a (almost) full world
> build. Things like support for !x86 targets in clang etc can be provided
> incrementally as well.

It would be great to get more support for external toolchains into the
tree.  This will become more and more important over the next few
years.

> At the moment, I do not plan to import the upstream LLVM or clang
> sources. src/external/llvm/Makefile has a checkout target using svn to
> get the "proven" revision as specified in Makefile.inc. This avoids
> having to deal with regular imports and repo churn associated.

That's a neat trick, but I feel it's not the right way to attack the
issues:

1.  checking existing version informatino, and optionally downloading,
verifying integrity, making sure pre-reqs are in place, configuring
for the host, building and packaging up the result are best done in
pkgsrc - that's what it's designed for.  Re-inventing a subset of this
in src strikes of point solutions and re-inventing wheels.

2. Doing this in src means that no binary packages for the toolchain.
For me, that's a necessity for an external toolchain.
(Continue reading)

Permalink | Reply | 13 comments |
headers
Antti Kantee | 3 Feb 2011 17:04
Picon
Picon

Re: Initial LLVM/clang patch

On Thu Feb 03 2011 at 16:39:12 +0100, Alistair Crooks wrote:
> > At the moment, I do not plan to import the upstream LLVM or clang
> > sources. src/external/llvm/Makefile has a checkout target using svn to
> > get the "proven" revision as specified in Makefile.inc. This avoids
> > having to deal with regular imports and repo churn associated.
> 
> That's a neat trick, but I feel it's not the right way to attack the
> issues:

To me it sounds like a great idea to make development smoother, at least
while llvm is experimental.

We discussed a similar approach even for non-experimental toolchains in
the 20101101 core meeting, but there was no clear consensus on that.
This experiment will allow us to better see the pros and cons of such
an approach.

> 1.  checking existing version informatino, and optionally downloading,
> verifying integrity, making sure pre-reqs are in place, configuring
> for the host, building and packaging up the result are best done in
> pkgsrc - that's what it's designed for.  Re-inventing a subset of this
> in src strikes of point solutions and re-inventing wheels.

Seems like the only required action is "make checkout" which runs two
svn commands.

> 2. Doing this in src means that no binary packages for the toolchain.

why?
(Continue reading)

Permalink | Reply | 8 comments |
headers
Alistair Crooks | 3 Feb 2011 17:18

Re: Initial LLVM/clang patch

On Thu, Feb 03, 2011 at 06:04:28PM +0200, Antti Kantee wrote:
> On Thu Feb 03 2011 at 16:39:12 +0100, Alistair Crooks wrote:
> > > At the moment, I do not plan to import the upstream LLVM or clang
> > > sources. src/external/llvm/Makefile has a checkout target using svn to
> > > get the "proven" revision as specified in Makefile.inc. This avoids
> > > having to deal with regular imports and repo churn associated.
> > 
> > That's a neat trick, but I feel it's not the right way to attack the
> > issues:
> 
> To me it sounds like a great idea to make development smoother, at least
> while llvm is experimental.
> 
> We discussed a similar approach even for non-experimental toolchains in
> the 20101101 core meeting, but there was no clear consensus on that.
> This experiment will allow us to better see the pros and cons of such
> an approach.
>
> > 1.  checking existing version informatino, and optionally downloading,
> > verifying integrity, making sure pre-reqs are in place, configuring
> > for the host, building and packaging up the result are best done in
> > pkgsrc - that's what it's designed for.  Re-inventing a subset of this
> > in src strikes of point solutions and re-inventing wheels.
> 
> Seems like the only required action is "make checkout" which runs two
> svn commands.

If you start going down this route, then version information needs to be
retained somewhere for the external toolchain. Some minimum versino to build
the source tree needs to be placed in the source tree.
(Continue reading)

Permalink | Reply | 7 comments |
headers
Joerg Sonnenberger | 3 Feb 2011 17:32
Picon

Re: Initial LLVM/clang patch

On Thu, Feb 03, 2011 at 04:39:12PM +0100, Alistair Crooks wrote:
> Hi Joerg,
> 
> On Thu, Feb 03, 2011 at 02:08:30AM +0100, Joerg Sonnenberger wrote:
> > attached patch + tarball contain enough magic to get a working clang for
> > AMD64. I could like to get this into the tree to make it simpler to test
> > and integrated the changes required for doing a (almost) full world
> > build. Things like support for !x86 targets in clang etc can be provided
> > incrementally as well.
> 
> It would be great to get more support for external toolchains into the
> tree.  This will become more and more important over the next few
> years.

I am working on cleaning up the compiler part of that in src/share/mk
and make it easier to use different compilers for different parts of the
tree. The biggest issue with that right now is libgcc and libstdc++ --
I'm not sure of the legal implications of building either with !GCC...

> > At the moment, I do not plan to import the upstream LLVM or clang
> > sources. src/external/llvm/Makefile has a checkout target using svn to
> > get the "proven" revision as specified in Makefile.inc. This avoids
> > having to deal with regular imports and repo churn associated.
> 
> That's a neat trick, but I feel it's not the right way to attack the
> issues:
> 
> 1.  checking existing version informatino, and optionally downloading,
> verifying integrity, making sure pre-reqs are in place, configuring
> for the host, building and packaging up the result are best done in
(Continue reading)

Permalink | Reply | 3 comments |
headers
Matthias Drochner | 3 Feb 2011 17:45
Picon
Picon
Favicon

Re: Initial LLVM/clang patch


joerg <at> britannica.bec.de said:
> The biggest issue with that right now is libgcc and libstdc++ -- I'm
> not sure of the legal implications of building either with !GCC...

Did you try the stuff in "compiler-rt" in the llvm repository?
There is also some "libcxx" as libstdc++ replacement, but it seems
that this is still under heavy development.

best regards
Matthias

------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Forschungszentrum Juelich GmbH
52425 Juelich
Sitz der Gesellschaft: Juelich
Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498
Vorsitzender des Aufsichtsrats: MinDirig Dr. Karl Eugen Huthmacher
Geschaeftsfuehrung: Prof. Dr. Achim Bachem (Vorsitzender),
Dr. Ulrich Krafft (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt,
Prof. Dr. Sebastian M. Schmidt
------------------------------------------------------------------------------------------------
------------------------------------------------------------------------------------------------
Permalink | Reply | 2 comments |
headers
Joerg Sonnenberger | 3 Feb 2011 18:05
Picon

Re: Initial LLVM/clang patch

On Thu, Feb 03, 2011 at 05:45:56PM +0100, Matthias Drochner wrote:
> 
> joerg <at> britannica.bec.de said:
> > The biggest issue with that right now is libgcc and libstdc++ -- I'm
> > not sure of the legal implications of building either with !GCC...
> 
> Did you try the stuff in "compiler-rt" in the llvm repository?
> There is also some "libcxx" as libstdc++ replacement, but it seems
> that this is still under heavy development.

I am aware of both. compiler-rt can be used to replace most of libgcc,
it will need some testing. IIRC FreeBSD run into some issues on MIPS for
example.

libcxx is currently not an option as replacement for libstdc++:
(1) It doesn't provide the equivalent of libsupc++. There is currently
no Open Source alternative.

(2) Last time I checked it depended heavily on POSIX 2008 locale
support, which we don't have. An alternative is stdcxx from ASF (under
Apache 2.0 license). I have that one working in a different tree.

Joerg
Permalink | Reply | 1 comment |
headers
Antti Kantee | 3 Feb 2011 17:57
Picon
Picon

Re: Initial LLVM/clang patch

On Thu Feb 03 2011 at 17:18:39 +0100, Alistair Crooks wrote:
> You haven't addressed my point, though - why are you trying to
> re-invent pkgsrc?

Why does our current toolchain reinvent pkgsrc?  I don't see any
fundamental difference in "externalness" if you import a suitable copy
into src and download it with src (gcc), or if you import the version
information of a suitable copy into src and download it on a per-need
basis (proposed llvm development approach).

--

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa
Permalink | Reply | 1 comment |
headers
Joerg Sonnenberger | 3 Feb 2011 21:50
Picon

Re: Initial LLVM/clang patch

On Thu, Feb 03, 2011 at 05:18:39PM +0100, Alistair Crooks wrote:
> On Thu, Feb 03, 2011 at 06:04:28PM +0200, Antti Kantee wrote:
> > Seems like the only required action is "make checkout" which runs two
> > svn commands.
> 
> If you start going down this route, then version information needs to be
> retained somewhere for the external toolchain. Some minimum versino to build
> the source tree needs to be placed in the source tree.

The revision numbers are already contained for the purpose of versioning
inside the binary. The checkout target obtains exactly that revision(s)
from the svn repository. All comparing etc is left to the subversion
checkout command, including merging local changes with upstream etc.

> A subversion client is required.

A subversion client is needed if you want to play or develop, yes. If
you build on NetBSD, you can obtain it from pkgsrc. If you are on Linux,
you can use whatever your distribution uses etc. I don't consider this
a big road block. If you want to help improve LLVM/clang, it is a
non-issue since you are going to deal with the upstream repository
anyway.

> > > 2. Doing this in src means that no binary packages for the toolchain.
> > 
> > why?
> 
> pkgsrc makes one for you by doing "make package". I can take the result,
> optionally sign it, and move it to any machine I want and use it there.
(Continue reading)

Permalink | Reply | 4 comments |
headers
Alistair Crooks | 4 Feb 2011 06:49

Re: Initial LLVM/clang patch

On Thu, Feb 03, 2011 at 06:57:32PM +0200, Antti Kantee wrote:
> On Thu Feb 03 2011 at 17:18:39 +0100, Alistair Crooks wrote:
> > You haven't addressed my point, though - why are you trying to
> > re-invent pkgsrc?
> 
> Why does our current toolchain reinvent pkgsrc?  I don't see any
> fundamental difference in "externalness" if you import a suitable copy
> into src and download it with src (gcc), or if you import the version
> information of a suitable copy into src and download it on a per-need
> basis (proposed llvm development approach).

Our current toolchain does not re-invent pkgsrc. The sources are all
under src, no attempt is made to fetch them externally. Because the
gcc sources are all in the tree, no integrity checks are needed. We
don't have to set up proxies in the network to enable us to download
sources, or be network connected.

Now, if some effort could be put into making pkgsrc grok svn co, and/or
git clone (already in wip, I think), maybe that would be a better idea.

Regards,
Alistair
Permalink | Reply | 0 comments |

Gmane