similar to: [LLVMdev] [cfe-dev] integrated-as on by default for ARM-ELF?

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

>> 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

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

> I wouldn't rely on that. > > I'm not sure what's your objective Agreed, thanks Renato. My objectives: 1) Add a patch to enable the integrated assembler by default when targeting ARM or Thumb with ELF. The patch is very tiny - you override a virtual method for the toolchain. But you do it in a base class so a little fragile. It deserves a test. 2) Demonstrate a

On Nov 18, 2013, at 6:18 PM, Greg Fitzgerald <garious at gmail.com> wrote: > Does the integrated assembler in the ARM backend support switching > between ARM and Thumb modes in the same file? Yes. > I'm having trouble with > the following assembly: > > .thumb_func > @ Enter ARM mode > adr r3, 1f > bx r3 > .align 4 That .align is probably not

Ideally Jurgen would cut up the code on github, put up an initial diff for a minimal viable tool, and then we would review it and then continue to copy code from the github repo into llvm and review it. I'm also willing to do that if Jurgen doesn't want to at this point though. I'd like the OK from Jurgen on that and I'd also like the OK from someone that the license stuff is all

> Regardless of any of that, given that TBD files _are_ an integral part of the apple platform, supporting them is certainly a necessity in order to have a working apple linker. So, if making LLD work for Apple/MachO is the justification for adding TBD support to LLVM, that seems self-evidently a reasonable thing to do. On the other hand, it looks like the LLD mach-o code is unmaintained

Does the integrated assembler in the ARM backend support switching between ARM and Thumb modes in the same file? I'm having trouble with the following assembly: .thumb_func @ Enter ARM mode adr r3, 1f bx r3 .align 4 .code 32 1: push {r7} mov r7, r12 svc 0x0 pop {r7} @ Enter thumb mode adr r3, 2f+1 bx r3 .code 16 2: bx lr As a standalone .s file, GNU-as

Benifits of TBD: 1) It's human readable and diffs on TBDs correspond to changes in the ABI. Diffs can be automatically added to review processes to ensure that changes to the ABI are reviewed. The TBDs also document your precise ABI. 2) The size is smaller which means they can be shipped in an SDK instead of binaries to reduce the size of an SDK 3) Stubs are producible from TBDs (or should be)

Hi Björn, It's correct - I tried casting the virtual function to a regular function. > But I also tried using the virtual function in the normal way. > Yes. If I understand your setup correctly you have a base class, Interface, which is currently compiled into your application, and you are creating a derived class in JIT'd code, and returning an Interface pointer to an instance of

FWIW, I also agree with Joerg that it would be very poor form to turn on -integrated-as when it can't even eat its own output. This has bitten me before (had to pass -no-integrated-as to reassemble .S output). I would really like to see it turned on in 3.4 however (just with fixes in place)! On 11 December 2013 08:16, Renato Golin <renato.golin at linaro.org> wrote: > On 10

Looks like the bug here is that the InlineAsm parser and the ARM code emitter point to two different TargetSubtargetInfo instances. The attached patch corrects the issue, but is incomplete. For starters, how can I remove that const_cast? Also, the patch does not restore the TargetSubtargetInfo to its original state. So if you changed from Thumb to ARM mode, but not back to Thumb, the code

On Tue, Dec 10, 2013 at 05:07:06PM +0000, Tim Northover wrote: > > I haven't created a bug report yet. From memory, the following things > > are missing and higher-priority: > > This is looking hopeful. > > > Pseudo-ops: > > .abicalls > > This is MIPS-only. Sorry, too much assembler in a short time. You are right. > > .fpu >

On Mon, Apr 9, 2018 at 10:11 PM, John Ericson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > Regardless of any of that, given that TBD files _are_ an integral part > of the apple platform, supporting them is certainly a necessity in order to > have a working apple linker. So, if making LLD work for Apple/MachO is the > justification for adding TBD support to LLVM, that

Seems like there are a few of us interested in this then. I new around here and don't really know how decisions are made, so what's next? Just open a diff with the entire library?? John On 04/10/2018 05:33 PM, Jake Ehrlich wrote: > Benifits of TBD: > 1) It's human readable and diffs on TBDs correspond to changes in the > ABI. Diffs can be automatically added to review

Done, thanks. And added a code review here: http://llvm-reviews.chandlerc.com/D2255 -Greg On Fri, Nov 22, 2013 at 8:48 AM, Amara Emerson <amara.emerson at arm.com> wrote: > Hi Greg, > > Can you post any patches to the commits list, it'll have a better chance of > some of us seeing it and taking a look there. > > Cheers, > Amara > > -----Original

> I just tried the above code in a .s file and it worked fine for me. > Can you show exactly what you’re seeing that looks wrong? Thanks Jim. I can only reproduce the issue when that code is inline assembly in a bitcode file. Attached is a bitcode file and Makefile to demonstrate. Calling 'make' will dump two object files 'c.o' and 'asm.o'. The former is created

Is there a reliable way to unit-test that LLVM's integrated assembler was used? I read through "ELF for the ARM Architecture" and my best guess has been to inspect .ARM.attributes in the elf-dump's section data, but both LLVM and GCC use "aeabi" for the vendor name. I've found several ways to distinguish the two (such as a magic number where GCC uses ELFOSABI_SYSV

Hi Jonathan, This looks a bit odd. Any reason for the unknown->none conflating in this way? For most (all) of the ports unknown-elf works the same as none-elf. I'm also not sure if someone decided to have, arm-codesourcery-elf that this would still work with the patch. Thoughts? -eric On Tue, Jun 24, 2014 at 7:35 AM, Amara Emerson <amara.emerson at gmail.com> wrote: > Hi Jon,

On Tue, Dec 10, 2013 at 02:26:53PM +0000, Renato Golin wrote: > In a nutshell, it seems to be our consensus that the integrated > assembly can now be turned on by default on ARM, and we should add > -no-integrated-as for the cases where it fails (like the kernel). It can't assemble basic PIC code as created by clang -S for ELF platforms. That's IMO a pretty big show stopper.