llvm dev - Nov 2015 - [RFC] Strategies for Bootstrapping Compiler-RT builtins

On Tue, Nov 3, 2015 at 6:33 AM, Martell Malone <martellmalone at
gmail.com> wrote:
> Just as a point for building the builtins shouldn't we just need
llvm-ar ?
Thanks for pointing this out and I hope llvm-ar is up to the task.
Even if targets must still port binutils, each step toward LLVM
self-reliance is a step in the right direction.

Without getting too far ahead of ourselves, refactoring built-ins into
a distinct library is a great place to start.

On Wed, Nov 4, 2015 at 12:12 AM, Steve King via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On Tue, Nov 3, 2015 at 6:33 AM, Martell Malone <martellmalone at
gmail.com> wrote:
>> Just as a point for building the builtins shouldn't we just need
llvm-ar ?
>
> Thanks for pointing this out and I hope llvm-ar is up to the task.
> Even if targets must still port binutils, each step toward LLVM
> self-reliance is a step in the right direction.
>
> Without getting too far ahead of ourselves, refactoring built-ins into
> a distinct library is a great place to start.
Before anyone starts refactoring binutils - if you're really zealous
or have some strong logical reason against it - there is the BSD elf
tools project

http://sourceforge.net/p/elftoolchain/wiki/Home/

>
> Cool. This then makes your other point about requiring LLVM tools less of
> an issue because the out-of-tree builds can use whatever tools you choose.
> We just need to make the builtins work so that you don’t need them already
> built.
With that in mind for an intiial solution before you get to stripping out
the cmake stuff so that it can do an out of tree bootstrap.
I have created a script that fits into the make bootstrapping method that
already exists.
Not sure if this is up for removal because it is not dependent on autotools?

Chris could you kindly add yourself as a reviewer to this
http://reviews.llvm.org/D14290


On Tue, Nov 3, 2015 at 6:15 PM, C Bergström <cbergstrom at pathscale.com>
wrote:
> On Wed, Nov 4, 2015 at 12:12 AM, Steve King via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> > On Tue, Nov 3, 2015 at 6:33 AM, Martell Malone <martellmalone at
gmail.com>
> wrote:
> >> Just as a point for building the builtins shouldn't we just
need
> llvm-ar ?
> >
> > Thanks for pointing this out and I hope llvm-ar is up to the task.
> > Even if targets must still port binutils, each step toward LLVM
> > self-reliance is a step in the right direction.
> >
> > Without getting too far ahead of ourselves, refactoring built-ins into
> > a distinct library is a great place to start.
>
> Before anyone starts refactoring binutils - if you're really zealous
> or have some strong logical reason against it - there is the BSD elf
> tools project
>
> http://sourceforge.net/p/elftoolchain/wiki/Home/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20151103/d63e53c9/attachment.html>

On 11/3/15 10:15 AM, C Bergström via llvm-dev wrote:
> On Wed, Nov 4, 2015 at 12:12 AM, Steve King via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> On Tue, Nov 3, 2015 at 6:33 AM, Martell Malone <martellmalone at
gmail.com> wrote:
>>> Just as a point for building the builtins shouldn't we just
need llvm-ar ?
>>
>> Thanks for pointing this out and I hope llvm-ar is up to the task.
>> Even if targets must still port binutils, each step toward LLVM
>> self-reliance is a step in the right direction.
>>
>> Without getting too far ahead of ourselves, refactoring built-ins into
>> a distinct library is a great place to start.
>
> Before anyone starts refactoring binutils - if you're really zealous
> or have some strong logical reason against it - there is the BSD elf
> tools project
>
> http://sourceforge.net/p/elftoolchain/wiki/Home/
builtins != binutils
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
-- 
Jon Roelofs
jonathan at codesourcery.com
CodeSourcery / Mentor Embedded