similar to: [LLVMdev] Integrated ARM assembler

Hi Renato, > is there anything holding the integrated assembler back from being on by default? For ARM-ELF, a couple missing pieces I see: 1) The assembly parser does not parse the ARM-ELF directives. 2) The Exception Handling ABI does not appear to be supported. Try this: $ echo "void a(){}" | clang -target arm-none-linux-gnueabi -mllvm -arm-enable-ehabi -integrated-as -c -xc -

Hi Greg, I'd also like to see the integrated assembler enabled, though I'm only very weakly connected to the 32-bit backend. > 1) The assembly parser does not parse the ARM-ELF directives. Renato asked about inline assembly here, but I think the key question is over the directives LLVM itself decides to generate as a result of Clang invocations. I had a very brief encounter last year

>> The assembly parser does not parse the ARM-ELF directives. > Is this for inline asm? Yep >> $ echo "void a(){}" | clang -target arm-none-linux-gnueabi -mllvm -arm-enable-ehabi -integrated-as -c -xc - >>Not implemented yet > Seems to work for me... ;) I see this just recently changed. I just confirmed the issue is in the 'release_32' branch, but not

On 5 February 2013 23:21, Greg Fitzgerald <garious at gmail.com> wrote: > > Is this for inline asm? > > Yep > In that case, using GAS is always a better options... for now. ;) What I'd prefer to see is if the integrated-as doesn't recognize the > option, clang should report a warning and switch to the 'no-integrated-as' > path. Thoughts? > The

Hi Keith, Anton, Logan, Last time we spoke about ARM unwinding, we agreed to have both CFI and directive variants in ARM, so that both EH and debuggers/profilers could correctly unwind the stack. The problem, obviously, is that we now have redundant information and I decided to have a go commoning them up. One of the issues, I think, is GNU compatibility (so GAS can generate the tables correctly

Hiya I am trying to compile a test case with latest LLVM 3.3 release using integrated assembler. I have looked through previous mailing discussion on this subject and it appears that perhaps by now the appropriate changes are checked-in however my test case is failing. Maybe I am missing something and not specifying appropriate options on the commandline. My setup: Host operating System: Ubuntu

On Nov 1, 2013, at 12:06 PM, David Peixotto <dpeixott at codeaurora.org> wrote: >>> I was thinking that without the .ltorg directive the constant pool >>> would go at the end of the section. >>> >> So where does the assembler place the constant pool(s) if that directive >> isn't present? I was under the impression it was always required. >

> > I was thinking that without the .ltorg directive the constant pool > > would go at the end of the section. > > > So where does the assembler place the constant pool(s) if that directive > isn't present? I was under the impression it was always required. >From my understanding it is not required. I see that GCC will place it at the end of the section. I don't

On 10 September 2010 04:47, Liu <proljc at gmail.com> wrote: > 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 Hi Liu, That doesn't work for me. $ clang -march=armv7-a -mcpu=cortex-a9 -ccc-host-triple arm-none-linux -ccc-gcc-name arm-none-linux-gnueabi-gcc alias.c clang: warning: unknown

> >>> I was thinking that without the .ltorg directive the constant pool > >>> would go at the end of the section. > >>> > >> So where does the assembler place the constant pool(s) if that > >> directive isn't present? I was under the impression it was always > required. > > > > From my understanding it is not required. I see

Hi, I'm pleased to announce that the MIPS integrated assembler is now good enough to recurse the compiler for MIPS32R2, build a bootable Linux kernel for MIPS32R2, and pass LNT testing for a variety of 32-bit MIPS targets. I've therefore enabled it by default for all 32-bit MIPS targets in both LLVM and Clang. We're not aiming for perfect GAS compatibility but you should find that

In an earlier email[1] I proposed adding support for the ldr pseud-instruction to the ARM integrated assembler. After some discussion the overall consensus seemed to be that it was worth adding. One concern was that we needed to have adequate testing. I promised to provide more details on what the behavior should be and provide some tests before starting the implementation. The FileCheck-ified

On 16 September 2015 at 21:56, Jim Grosbach <grosbach at apple.com> wrote: > Why do we care about GAS? We have an assembler. It's not that simple. There are a lot of old code out there, including the Linux kernel which we do care a lot, that only compiles with GAS. We're slowly moving the legacy code up to modern standards, and specifically some kernel folks are happy to move up

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

On 20 November 2012 19:49, Tim Northover <t.p.northover at gmail.com> wrote: > I'd be in favour of it. All of the gaps I'm aware of (haphazard build > attributes mainly) are equally applicable to both integrated and GAS > assembly. It's possible we mis-tag a section or a symbol somehow, but > hopefully nothing substantial. Is there any test using the integrates

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

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 15 March 2014 17:06, Logan Chien <tzuhsiang.chien at gmail.com> wrote: > I would like to know what do you mean by "commoning them up"? Hi Logan, That'd be reducing ARM directives in favour of CFI, but as I said (and you too), GNU compatibility will probably be an issue for a very long time. > For the space issue, I personally don't think this is a big issue.

Dear list members, I ran into the problem that neither clang 3.4 nor current trunk versions of clang ar not usable for Objective-C on ARM. This is described in the bug report http://llvm.org/bugs/show_bug.cgi?id=18622 clang 3.3 didn't have that problem, but I also need the exception handling for ARM that is only available in recent builds, as I learned. I would like to get in touch with

All, we recently had a user report an issue associated with utilizing LLVM-MC as the desired assembler in place of GNU’s GAS. They are utilizing a tangled mess of automake scripts to build this respective software package and have decided to manually override the “CCAS” macro to point directly to LLVM-MC (rather than using Clang). Apparently, automake assumes that whatever “compiler” (as it is