llvm dev - Mar 2009 - [LLVMdev] Consumer ARM platform suitable for LLVM development?

On Mar 18, 2009, at 11:30 AMPDT, Misha Brukman wrote:
> Can someone with llvm-gcc/ARM expertise (Dale?) please review  
> Sandeep's patch?  The patch works for me in building an LLVM-based  
> cross-compiler from x86_64/Linux to ARM/Linux.
> I have been able to build without the patch to the asm file, but  
> several people have reported needing the asm patch on
http://llvm.org/PR2545
>  .
Looks OK to me.  The asm file is the only thing I'd have reservations  
about (that isn't marked as a local change, btw, and I don't think it  
was), but the parentheses should work fine.
> On Thu, Mar 12, 2009 at 8:39 PM, Sandeep Patel <deeppatel1987 at
gmail.com
> > wrote:
> Attached is the patch I've been building arm-eabi with, which might
> help with linux-gnueabi. I disable multilib to get around several bugs
> with thumb. I build cross binutils first, then llvm, then llvm-gcc
> with newlib merged in.
>
> The following bugs need to be addressed for these non-Darwin ARM  
> targets:
> 1388
> 2313
> 2545
> 2985
>
> deep
>
> On Fri, Mar 13, 2009 at 12:30 AM, Misha Brukman <brukman at
gmail.com>
> wrote:
> > On Thu, Mar 12, 2009 at 6:17 AM, Dietmar Ebner <ebner at
complang.tuwien.ac.at
> >
> > wrote:
> >>
> >> On Mar 11, 2009, at 9:44 PM, Misha Brukman wrote:
> >> > The problem I've had is building an LLVM cross-compiler
from
> Linux/
> >> > x86 to Linux/ARM (as has another llvm-dev poster).  Someone
> >> > mentioned to me off-list that he managed to get it to build,
> but I
> >> > haven't been able to reproduce the build using his
instructions
> >> > (I'll post my results in another thread).
> >>
> >> I've been successfully experimenting with an
arm-softfloat-linux-
> gnu
> >> cross-compiler at the time of llvm 2.1. The easiest way to get
this
> >> working is to use Dan Kegel's crosstool to build a regular gcc
> >> toolchain. This will give you binutils, libgcc, and glibc, which  
> you
> >> will need anyway.
> >
> > I've been trying to build for the target arm-none-linux-gnueabi,  
> using the
> > appropriate pre-built CodeSourcery toolchain, hence avoiding  
> building my own
> > gcc crosstool prior to starting building LLVM and LLVM-GCC.  LLVM  
> builds
> > just fine, it's building llvm-gcc that gives me this error:
> >
> > gcc -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall - 
> Wwrite-strings
> > -Wstrict-prototypes -Wmissing-prototypes -DHAVE_CONFIG_H - 
> DGENERATOR_FILE
> > -I. -Ibuild -I../../../../src/llvm-gcc4.2-2.5.source/gcc
> > -I../../../../src/llvm-gcc4.2-2.5.source/gcc/build
> > -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../include
> > -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../libcpp/include
> > -I../../../../src/llvm-gcc4.2-2.5.source/gcc/../libdecnumber
> > -I../libdecnumber -I/tmp/llvm-project/install/x86_64-arm/llvm/ 
> include
> > -I/tmp/llvm-project/src/llvm-2.5/include -DENABLE_LLVM
> > -I/tmp/llvm-project/install/x86_64-arm/llvm/include  -D_DEBUG  - 
> D_GNU_SOURCE
> > -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS   -o build/ 
> gencondmd.o
> > build/gencondmd.c
> >
> > ../../../../src/llvm-gcc4.2-2.5.source/gcc/config/arm/arm.md:4788:  
> error:
> > ‘MACHO_DYNAMIC_NO_PIC_P’ undeclared here (not in a function)
> >
> > This tells me there are some Darwin-specific bits in arm.md which  
> shouldn't
> > be there (MachO is Mac OS X-specific).  I'm using the attached  
> script
> > llvm-arm-crosstool.sh to configure/build/install LLVM and LLVM-GCC  
> from the
> > 2.5 release.  If anyone wants to try it out and see if it works  
> for them,
> > I'd love to hear their experiences.
> >
> > If any ARM/GCC experts know how to fix arm.md to not refer to
> > Darwin-specific macros, that would be great, too.
> >
> >> Building llvm-gcc was relatively painless. The only problem
I've
> >> encountered was that my target had no hardware floating point  
> support
> >> and the endianess for the softfloat implementation (libgcc)  
> differed
> >> from integer endianess, which required some patches at the llvm  
> side.
> >> I have not checked if this is still necessary. If you run into the
> >> same problems, I would be happy to share the patch (which I have
> >> updated to llvm 2.4 at some point).
> >
> > I would be interested in seeing your patch, if you wouldn't mind  
> sharing
> > it.  Bonus points if you have a script similar to mine above to  
> simplify the
> > entire process, or your notes/directions that I can convert into an
> > easy-to-run script.  :-)
> >
> > Thanks,
> > Misha
> >
> > _______________________________________________
> > LLVM Developers mailing list
> > LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
> >
> >
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090318/825256f5/attachment.html>

2009/3/18 Dale Johannesen <dalej at apple.com>
> On Mar 18, 2009, at 11:30 AMPDT, Misha Brukman wrote:
>
> Can someone with llvm-gcc/ARM expertise (Dale?) please review Sandeep's
> patch?  The patch works for me in building an LLVM-based cross-compiler
from
> x86_64/Linux to ARM/Linux.
> I have been able to build without the patch to the asm file, but several
> people have reported needing the asm patch on http://llvm.org/PR2545 .
>
> Looks OK to me.
>
Thanks for the review.  Sandeep, I've committed your patch (with some
modifications) to arm.h -- please sync and see if this version works for
you.

> The asm file is the only thing I'd have reservations about (that
isn't
> marked as a local change, btw, and I don't think it was), but the
> parentheses should work fine.
>
I haven't yet submitted the .asm patch -- I'm also curious how the /*
LLVM
LOCAL */ markers work in the Apple merges when it's not an addition but
rather a modification, e.g.:

-       THUMB_DIV_MOD_BODY 1
+       /* LLVM LOCAL */
+       THUMB_DIV_MOD_BODY(1)

Will Apple merger think that this is a new line added in the LLVM and
complain that it's missing a line without the parens from the Apple side,
and end up inserting both?  I admit I'm still a bit unclear as to how the
auto-patcher works in all cases.

Would it make sense to do these fixes on the Apple side of the tree, so that
Apple and LLVM are in agreement on this?  It looks like a trivial change.
Or I can make a patch with /* APPLE LOCAL */ markers so that Apple's and
public LLVM SVN don't differ so much for such a change.

Let me know what you prefer.

Misha
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090319/b60fcf8c/attachment.html>

Hi, Misha
> I haven't yet submitted the .asm patch -- I'm also curious how the
/* LLVM
> LOCAL */ markers work in the Apple merges when it's not an addition but
> rather a modification, e.g.:
Afair, it does not matter whether you added something or changed. Just
use markers to indicate the place of change.

-- 
With best regards, Anton Korobeynikov
Faculty of Mathematics and Mechanics, Saint Petersburg State University

On Mar 19, 2009, at 7:31 AMPDT, Misha Brukman wrote:
> 2009/3/18 Dale Johannesen <dalej at apple.com>
> On Mar 18, 2009, at 11:30 AMPDT, Misha Brukman wrote:
>> Can someone with llvm-gcc/ARM expertise (Dale?) please review  
>> Sandeep's patch?  The patch works for me in building an LLVM-based
>> cross-compiler from x86_64/Linux to ARM/Linux.
>> I have been able to build without the patch to the asm file, but  
>> several people have reported needing the asm patch on
http://llvm.org/PR2545
>>  .
>
> Looks OK to me.
>
> Thanks for the review.  Sandeep, I've committed your patch (with  
> some modifications) to arm.h -- please sync and see if this version  
> works for you.
>
> The asm file is the only thing I'd have reservations about (that  
> isn't marked as a local change, btw, and I don't think it was), but
> the parentheses should work fine.
>
> I haven't yet submitted the .asm patch -- I'm also curious how the
/
> * LLVM LOCAL */ markers work in the Apple merges when it's not an  
> addition but rather a modification, e.g.:
>
> -       THUMB_DIV_MOD_BODY 1
> +       /* LLVM LOCAL */
> +       THUMB_DIV_MOD_BODY(1)
>
> Will Apple merger think that this is a new line added in the LLVM  
> and complain that it's missing a line without the parens from the  
> Apple side, and end up inserting both?  I admit I'm still a bit  
> unclear as to how the auto-patcher works in all cases.
This syntax is fine; added lines and changed existing lines are  
treated the same.
> Would it make sense to do these fixes on the Apple side of the tree,  
> so that Apple and LLVM are in agreement on this?  It looks like a  
> trivial change.  Or I can make a patch with /* APPLE LOCAL */  
> markers so that Apple's and public LLVM SVN don't differ so much
for
> such a change.
These trees diverged several years back and there are hundreds of  
differences by now.  Removing one isn't going to help.  (Putting them  
back together has been discussed, and may happen someday, but not  
soon.  If this happens it will probably happen by having the LLVM tree  
be used instead of the Apple gcc tree, with whatever modifications are  
needed to get it to work in non-LLVM mode.  #undef ENABLE_LLVM is  
supposed to make this happen but it is not tested regularly, and you  
know what that means.)
> Let me know what you prefer.
>
> Misha
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20090319/207d076f/attachment.html>