similar to: [LLVMdev] more ARM bits

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

Hello, I am trying to bootstrap on ARM linux EABI using a qemu chroot to better test my changes on at least one more architecture. I am using the following configure line: ../gcc/configure --prefix=/home/espindola/install/ --program-prefix=llvm- --enable-languages=c --disable-shared --disable-multilib --enable-llvm=/home/espindola/build --enable-checking arm-linux-gnueabi The bootstrap fails

Rafael, Remember that the qemu <= 0.9.0 can misexecute code compiled by LLVM. I think you should test using qemu CVS. Lauro 2007/11/2, Rafael Espindola <espindola at google.com>: > Hello, > > I am trying to bootstrap on ARM linux EABI using a qemu chroot to > better test my changes on at least one more architecture. > > I am using the following configure line: >

Hi Jason, Jim, Rafael, We had plans to work on ARM MC (asm and elf), good to see there is an interest, and we'd be glad to help. The ARM part of MC is almost empty, so there's a lot of work in there, probably even before writing the assembly/ELF writers. Also, AFAIK, there is no ELF writer for MC, so wouldn't be good to write one specific for the ARM platform, but keep things generic

> The ARM part of MC is almost empty, so there's a lot of work in there, > probably even before writing the assembly/ELF writers. Also, AFAIK, > there is no ELF writer for MC, so wouldn't be good to write one > specific for the ARM platform, but keep things generic as much as > possible. There is one for x86/x86-64 on the works. It has some limitations, but can produce

Hi, I stopped into IRC to ask about a problem I've been having using Clang in conjunction with LLD to compile and link for an embedded project on Cortex-M ARM processor. First, I am able to separately compile with a call to clang and link with a call to lld, but I cannot use clang to link using lld using the -fuse-ld=lld flag. I have the output from `clang -v -fuse-ld=lld -target

hi, So... I followed the following steps in order to compile the llvm-gcc frontend. The single problem is that mentioned in the previous message: llvm-gcc HelloWorld.c /home/LLVM/install/lib/gcc/arm-elf/4.2.1/../../../../arm-elf/bin/ld: this linker was not configured to use sysroots collect2: ld returned 1 exit status 1. I have compiled the binutils for the arm-none-eabi target. Options:

On 12/2/06, Jim Laskey <jlaskey at apple.com> wrote: > Rafael, > > Please bracket portions of your changes that involve modification of > C/C++ source code. For cases of modifying configuration scripts and > make files, use your best judgement. Obviously having the brackets > emitted in generated code is problematic (line numbers et cetera), so > don't bother in

On Mon, Oct 5, 2009 at 2:21 PM, Rafael Espindola <espindola at google.com> wrote: > 2009/10/4 Sandeep Patel <deeppatel1987 at gmail.com>: >> There needs to be a build step >> somewhere in llvm-gcc that copies it into libexec/<gcc >> poop>/libLLVMgold.so, but I've been doing that manually for now. > > Yes, this is bad. The problem is that we build

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

> 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

On 3 May 2017 at 08:01, Rafael Avila de Espindola via llvm-dev <llvm-dev at lists.llvm.org> wrote: > Can you provide a .s file that shows the difference? I managed to reproduce it by compiling 'char *var = "whatever";' in debug mode (so clang -target arm-none-eabi tmp.c -g"). Direct compile leaves no assembler-local strings, but for some reason going via -S does.

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

On 11/24/06, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > 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 >

Dear LLVM developers, Hello, I'm trying to find a way of cross-compiling my c code against Baremetal Cortex-M device (so target triple will be arm-none-eabi) only using LLVM/Clang, and not using anything from GNU (ld or libc). I'm doing this to know which one of LLVM/clang and GCC produces smaller flash image size because saving flash is a big deal in our projects. 1) When I just follow

On 26 November 2013 16:44, Renato Golin <renato.golin at linaro.org> wrote: > On 26 November 2013 15:36, Rob Stewart <robstewart57 at gmail.com> wrote: >> >> $ clang -v -target armv7a-linux-eabi -mcpu=cortex-a9 -mfloat-abi=soft >> -mfpu=neon helloworld.c > > Hi Rod, I'm honoured. (But Rob is also OK) :-) > You need cross-binutils installed on your

On Mon, Oct 5, 2009 at 8:04 PM, Rafael Espindola <espindola at google.com> wrote: >> I have no idea how to reduce this. >> >> Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8 >> --with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the >> bitcode will be "armv7-eabi" but the actual CPU subtarget won't

> That would work for gold, but what about nm, etc.? You would still need to copy it :-( > I have no idea how to reduce this. > > Configure llvm-gcc for "arm-eabi" and use "--with-cpu=cortex-a8 > --with-fpu=neon --with-abi=aapcs --with-float=hard". The triple in the > bitcode will be "armv7-eabi" but the actual CPU subtarget won't be > known

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