similar to: [LLVMdev] Compiler-RT for ARM-EABI target

I'm trying to build compiler-rt for bare-metal arm-none-eabi targets. I don't need any of the existing compiler-rt functionality(though the builtin(s) may be nice). I want to extend it with custom functionality for the arm-none-eabi targets. Can anyone give me some pointers on how to go about doing this. I'm currently doing a combined build of llvm, clang and compiler-rt for both

Hello, Is there a quick tutorial to build the LLVM toolchain from a Linux or Mac OS X x86 host for an ARM v4/v5/v6 ELF target? It this configuration supported, and is it possible to build the Clang compiler for this host/target combination? I know about the installation page, but I keep failing to build this toolchain with LLVM 2.7. Maybe it is not (yet) supported? Thanks, Manu

trying this: clang -march=armv7-a -mcpu=cortex-a9 -ccc-host-triple arm-none-linux -ccc-gcc-name arm-none-linux-gnueabi-gcc a.c 2010/9/10 Emmanuel Blot <eblot.ml at gmail.com>: > Hello, > > Is there a quick tutorial to build the LLVM toolchain from a Linux or > Mac OS X x86 host for an ARM v4/v5/v6 ELF target? > It this configuration supported, and is it possible to build the

> There isn't one at the moment, ideally it should figure it out, but I haven't looked much into it - it may be that this isn't working yet. I should say that I'm still a bit confused: Is it possible to build for ARM CPUs now? 1/ from which hosts (x86-*-* ?) 2/ for which targets (arm-*-* ?) 3/ what are the supported tools for ARM targets: a/ llvm-gcc (gcc 4.2)?

I'm developing something for an ARMv7-A system in big-endian mode. I'm trying to use clang as the compiler for it. Things have been going well so far, but I've hit a point where the generated code is depending on functions which are implemented in compiler-rt. Since I'm doing the building on an amd64 machine, the compiler-rt that I have only targets x86/amd64. So, I have three

> Looks as though whomever implemented the call to __aeabi_idiv0 wanted > to be conservative for non EABI targets. How could it prevent him from providing default implementation of __aeabi_idiv0() for EABI targets? > AFAIK, gnueabi targets recognize all EABI functions, so that should > work well. Not sure I understand you, nothing in compiler-rt defines these functions, they are

Dear all, I am using initramfs and from the kernel document, I know klibc. So i decide to use it. We are working on marvell pxa310 (bought from Intel), and with the tools chain from marvell, I comple klibc as follows: klibc-1.5> ln -s /home/zjujoe/svn/mhlv_2.6/working/songlixin/20081007_kernel_tflashupdate/ linux klibc-1.5>cat 1.sh export KLIBCARCH=arm export

On Feb 8, 2007, at 10:46 AM, Lauro Ramos Venancio wrote: > I'm facing a problem with functions arguments. ARM EABI defines that > 8-bytes arguments must be 8-bytes aligned. For example: > > void @f(i32 %a, i64 %b) > > ARM EABI: > r0 <- %a > r2,r3 <- %b Ok. I suppose this makes it easier to use 64 bit store instructions. > > Darwin: > r0 <- %a >

On 18 April 2016 at 16:33, Silviu Baranga <Silviu.Baranga at arm.com> wrote: > Doing a grep "eabi" * -R | grep darwin in llvm I found the test divmod-eabi.ll > which uses the triple armv7-apple-darwin-eabi. What format does that have? Certainly not ELF. :) But I didn't mean "has eabi on triple", but "is in none-eabi mode", which may have to check a

On 18 April 2016 at 16:18, Silviu Baranga <Silviu.Baranga at arm.com> wrote: > This doesn't look like something ACLE specific (I can't find it in the ACLE doc). Sorry, I didn't mean it was ACLE, only that you guys were fiddling with macros. :) > This seems to be a generic macro. I think it would make sense to define it > if we know we're emitting ELF. Since the

Hi, I was comparing the way LLVM generates the exception table and it looks a bit different from what GCC (arm-none-eabi-g++) generates. Maybe that's because clang is not generating ARM IR when I do: $ clang -c -emit-llvm -march=arm -mcpu=cortex-a8 -mtriple=arm-none-eabi exception.cpp -o exception.clang.bc clang: warning: argument unused during compilation: '-mcpu=cortex-a8' clang:

Attached is a port of the new ARM eabi from gcc 4.1 to the llvm-gcc branch. With this patch I am able to bootstrap the 4.0 branch using the new eabi. The llvm-gcc branch fails with ------------------------------------ internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14372 ------------------------------------ But I believe that this is an unrelated problem and I will

I'm facing a problem with functions arguments. ARM EABI defines that 8-bytes arguments must be 8-bytes aligned. For example: void @f(i32 %a, i64 %b) ARM EABI: r0 <- %a r2,r3 <- %b Darwin: r0 <- %a r1,r2 <- %b void @g(i32 %a, i32 %b, i32 %c) ARM EABI or Darwin: r0 <- %a r1 <- %b r2 <- %c The problem is: I can't differ a i64 argument of two i32 arguments in

Hi, What would be the proper syntax in a C file, using inline assembly, to load a immediate value into an ARM register using clang & integrated assembler? The following syntax is rejected by LLVM: // clang -target armv7em-none-eabi -mthumb #define CONSTANT 0x1234 void __attribute__((naked)) foo(void) { asm volatile ( "ldr r0, =%0 \n"

On 9 December 2013 11:51, Joerg Sonnenberger <joerg at britannica.bec.de> wrote: > Part of the concern is that the same code using / does call __aeabi_idiv > and __aeabi_uidiv. Hi Joerg, I can see the error, and it's just a bad selection of choices. I was wrong in assuming that the "eabi" at the end would always force it: $ clang -target arm-elf-eabi -S mod.c -o - |

Attached is a port of the new ARM eabi from gcc 4.1 to the llvm-gcc branch. With this patch I am able to bootstrap the 4.0 branch using the new eabi. The llvm-gcc branch fails with ------------------------------------ internal compiler error: in prune_unused_types_update_strings, at dwarf2out.c:14372 ------------------------------------ But I believe that this is an unrelated problem and I will

On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote: > I can see the error, and it's just a bad selection of choices. I was > wrong in assuming that the "eabi" at the end would always force it: > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > .file "mod.c" > bl __modsi3 > bl __umodsi3 I was discussing this with Tim on IRC and he

Hi Here are a few unintegrated patches, just tested against 2.2rc7: 1) NetBSD's getmntinfo uses struct statvfs while other BSD use struct statfs http://ftp.espci.fr/shadow/manu/patch-ak 2) NetBSD 5.x net_getunixcred() support. Build on NetBSD, but not tested (I am testing on NetBSD 6.0): http://ftp.espci.fr/shadow/manu/patch-src_lib_net.c 3) Increase authentication buffer size so that it

On Mon, Sep 27, 2010 at 8:50 AM, Dennis Taul <dtaul at codeaurora.org> wrote: > > I am new to LLVM but have perused the code alongside using llvm-gcc > and CLANG to build ARM EABI objects. > > Based on this superficial analysis it appears that LLVM currently does > not support the ARM Exception Handling ABI (as defined under the > EABI). > > Can anyone comment on

On Mon, Dec 09, 2013 at 03:11:45PM +0100, Joerg Sonnenberger wrote: > On Mon, Dec 09, 2013 at 01:58:29PM +0000, Renato Golin wrote: > > I can see the error, and it's just a bad selection of choices. I was > > wrong in assuming that the "eabi" at the end would always force it: > > > > $ clang -target arm-elf-eabi -S mod.c -o - | grep mod > > .file