Displaying 20 results from an estimated 40000 matches similar to: "[LLVMdev] [cfe-dev] integrated-as on by default for ARM-ELF?"
2013 Feb 05
1
[LLVMdev] [cfe-dev] Integrated ARM assembler
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
2013 Feb 05
0
[LLVMdev] [cfe-dev] Integrated ARM assembler
>> 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
2013 Feb 05
2
[LLVMdev] [cfe-dev] Integrated ARM assembler
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
2012 Nov 20
3
[LLVMdev] Does LLVM sign ARM ELFs?
> 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
2013 Nov 19
0
[LLVMdev] switching ARM modes and integrated-as
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
2018 Apr 10
0
[cfe-dev] [RFC] Open sourcing and contributing TAPI back to the LLVM community
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
2018 Apr 10
0
[cfe-dev] [RFC] Open sourcing and contributing TAPI back to the LLVM community
> 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
2013 Nov 19
2
[LLVMdev] switching ARM modes and integrated-as
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
2018 Apr 10
0
[cfe-dev] [RFC] Open sourcing and contributing TAPI back to the LLVM community
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)
2018 Feb 22
0
[cfe-dev] Calling virtual elf functions under windows -> Adding ASM code
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
2013 Dec 11
0
[LLVMdev] [cfe-dev] ARM Integrated Assembler
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
2013 Nov 22
0
[LLVMdev] switching ARM modes and integrated-as
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
2013 Dec 10
0
[LLVMdev] [cfe-dev] ARM Integrated Assembler
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
>
2018 Apr 10
3
[cfe-dev] [RFC] Open sourcing and contributing TAPI back to the LLVM community
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
2018 Apr 10
2
[cfe-dev] [RFC] Open sourcing and contributing TAPI back to the LLVM community
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
2013 Nov 22
0
[LLVMdev] switching ARM modes and integrated-as
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
2013 Nov 19
3
[LLVMdev] switching ARM modes and integrated-as
> 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
2014 Jun 24
2
[LLVMdev] [cfe-dev] [PATCH] triples for baremetal
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,
2012 Nov 20
3
[LLVMdev] Does LLVM sign ARM ELFs?
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
2013 Dec 10
0
[LLVMdev] [cfe-dev] ARM Integrated Assembler
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.