search for: thumb_func

..._orig/klibc/arch/arm/setjmp-thumb.S 2002-08-21 07:12:10.000000000 -0700 +++ klibc-0.114/klibc/arch/arm/setjmp-thumb.S 2004-02-22 04:39:00.000000000 -0800 @@ -19,7 +19,7 @@ # .text - .align 4 + .align 1 @ For ARM, align means align on a 2^n boundary .globl setjmp .type setjmp, #function .thumb_func @@ -37,7 +37,7 @@ .size setjmp,.-setjmp .text - .align 4 + .align 1 @ For ARM, align means align on a 2^n boundary .globl longjmp .type longjmp, #function .thumb_func diff -ruN klibc-0.114_orig/klibc/include/sys/types.h klibc-0.114/klibc/include/sys/types.h --- klibc-0.114_orig/klibc/i...

...ake sure that there are @RESERVED_C_STACK_BYTES@ on the * C-stack. This is done to reserve some space for the allocation of * temporaries in STG code. If you are then curious how ARM-specific StgRun implementation looks, then here it is: #ifdef arm_HOST_ARCH #if defined(__thumb__) #define THUMB_FUNC ".thumb\n\t.thumb_func\n\t" #else #define THUMB_FUNC #endif StgRegTable * StgRun(StgFunPtr f, StgRegTable *basereg) { StgRegTable * r; __asm__ volatile ( /* * save callee-saves registers on behalf of the STG code. */ "stmfd sp!, {r4-r1...

On 29 June 2012 17:46, Karel Gardas <karel.gardas at centrum.cz> wrote: > Yes and no. Shortly: original GHC/ARM/LLVM port was done by Stephen on > ARMv5/Qemu IIRC. I've later added whole VFP support and ARMv7 support. The > code in GHC is properly #ifdefed, so if there is no VFP available on pre > ARMv6, then it's not used. ie. GHC STG floating points regs are then >

...S new file mode 100644 index 0000000..1e81f8e --- /dev/null +++ b/usr/klibc/arch/arm/crt0.S @@ -0,0 +1,23 @@ +# +# arch/arm/crt0.S +# +# void _start(void) +# { +# __libc_init(elf_structure, atexit_ptr); +# } +# + + .text + .balign 4 + .type _start,#function + .globl _start + +#ifdef __thumb__ + .thumb_func +#endif + +_start: mov r0, sp + mov r1, #0 + bl __libc_init + + .size _start,.-_start diff --git a/usr/klibc/arch/arm/setjmp.S b/usr/klibc/arch/arm/setjmp.S new file mode 100644 index 0000000..1841bc7 --- /dev/null +++ b/usr/klibc/arch/arm/setjmp.S @@ -0,0 +1,102 @@ +# +# arch/arm/setjmp.S +# +# se...

Hi Renato, On 06/25/12 12:13 AM, Renato Golin wrote: > Hi Karel, > > I understand this patch has already been merged (to 3.0), so don't > take my question as stopping the merge to head, I'm just making sure I > got it right... The rest looks correct. > > + CCIfType<[v2f64], CCAssignToReg<[Q4, Q5]>>, > + CCIfType<[f64], CCAssignToReg<[D8, D9,

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 can compile it but with "clang -integrated-as", I get errors. If using...

...sure whether the "-Wl,-read_only_relocs,suppress" option would really work. /* ==begin table.c== */ int data_table[] = {0xff, 0xff}; /* ==end table.c== */ /* ==begin use_table_m1.s== * use table by LDR */ .text .syntax unified .align 4 .global foo .thumb .thumb_func foo: LDR r0,[PC,#4] BX lr .long _data_table /* ==end use_table_m1.s== */ /* ==begin use_table_m2.s== * use table by code from compiler's assembly out put */ .text .syntax unified .align 4 .global foo .thumb .thumb_func foo: /* these li...

Hi Ashi, > ld: illegal text-relocation to _data_table in table.o from foo in > use_table.o for architecture armv7 It looks like you're using iOS. I'm not familiar with the exact workings of that platform, but I think a similar message would occur in ELF-land. If iOS *is* comparable, your issue is that symbols in dynamically loaded objects can't (usually) be referenced directly

...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 what you want. ARM .align is a power of two, so you’re aligning at 16 bytes here, not 32-bits. > >> .code 32 >> 1: push {r7} >> mov r7, r12 >> s...

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 what you want. ARM .align is a power of two, so you’re aligning at 16 bytes here, not 32-bits. > .code 32 > 1: push {r7} > mov r7, r12 > svc 0x0 > pop {r7} > @ Enter thumb m...

...b/Arm) and the latter restoring it, by > emiting the $d and $a/t respectively. > > Does it seem like a good initial approach? > > Continuing... It seems MCELFStreamer already has a EmitThumbFunc, > which looks to me as the wrong place to be. That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function. > I'd imagine MCELFStreamer > would have EmitFunc and MCARMELCStreamer (or whatever) would identify > its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being > pedantic, even that is still...

....eabi_attribute 24, 1 > .eabi_attribute 25, 1 > .eabi_attribute 44, 1 > .file "a.c" > .section .text.out_char,"ax",%progbits > .globl out_char > .align 2 > .type out_char,%function > .code 16 > .thumb_func > out_char: > push.w {r11, lr} > mov r1, r0 > movs r0, #0 > bl platform_putchar > pop.w {r11, pc} > .Ltmp0: > .size out_char, .Ltmp0-out_char > > The one question I have is: > why can't this out_char function be compiled...

...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 what you want. ARM .align is a power of two, so you're aligning at 16 bytes here, not 32-bits. > >> .code 32 >> 1: push {r7} >> mov r7, r12 >&gt...

...it, by >> emiting the $d and $a/t respectively. >> >> Does it seem like a good initial approach? >> >> Continuing... It seems MCELFStreamer already has a EmitThumbFunc, >> which looks to me as the wrong place to be. > > That's just the handler for the .thumb_func directive. It has nothing to do with emitting the contents of the actual function. > >> I'd imagine MCELFStreamer >> would have EmitFunc and MCARMELCStreamer (or whatever) would identify >> its type and call the appropriate EmitThumbFunc/EmitARMFunc. Being >> pedantic...

....eabi_attribute 25, 1 >> .eabi_attribute 44, 1 >> .file "a.c" >> .section .text.out_char,"ax",%progbits >> .globl out_char >> .align 2 >> .type out_char,%function >> .code 16 >> .thumb_func >> out_char: >> push.w {r11, lr} >> mov r1, r0 >> movs r0, #0 >> bl platform_putchar >> pop.w {r11, pc} >> .Ltmp0: >> .size out_char, .Ltmp0-out_char >> >> The one question I have is: >> why...

..._attribute 25, 1 > > .eabi_attribute 44, 1 > > .file "a.c" > > .section .text.out_char,"ax",%progbits > > .globl out_char > > .align 2 > > .type out_char,%function > > .code 16 > > .thumb_func > > out_char: > > push.w {r11, lr} > > mov r1, r0 > > movs r0, #0 > > bl platform_putchar > > pop.w {r11, pc} > > .Ltmp0: > > .size out_char, .Ltmp0-out_char > > > > The one question I have is: &gt...

...from foo in use_table.o for architecture armv7 Do you have any suggestion to solve this? Thanks! //==begin table.c== int data_table[] = {0xff, 0xff}; //==end table.c== //==begin use_table.s == .text .syntax unified .align 4 .global foo .thumb .thumb_func foo: PUSH {lr} @LDR r0,[PC,#2] .long _data_table POP {pc} //==end use_table.s== //==begin Makefile== CC = /Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang CFLAG = -arch armv7 -mcpu=cortex-a9 -isysroot /Applications/Xcode.app/Contents/Developer/P...

On 13 June 2015 at 04:12, Saleem Abdulrasool <compnerd at compnerd.org> wrote: > The behavior was taken from GAS. I don't know if there are applications > using this and dependent on the behavior. Given that this is a GNU > extension, I think its better to keep the behavior similar to GAS rather > than implement and diverge. I kind of agree with Saleem, here. We don't

...n't match + # the label handling below (if $prefix would be empty). + $prefix = "; "; push(@proc_stack, $proc); - s/^[A-Za-z_\.]\w+/$&:/; + s/^[A-Za-z_\.]\w+/$symprefix$&:/; } $prefix = $prefix."\t.thumb_func; " if ($thumb); s/\bPROC\b/@ $&/; @@ -172,7 +183,7 @@ while (<>) { my $proc; s/\bENDP\b/@ $&/; $proc = pop(@proc_stack); - $_ = "\t.size $proc, .-$proc".$_ if ($proc); + $_ = "\t.size $proc, .-$proc".$_ if ($pr...

...m> 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 what you want. ARM .align is a power of two, > so you're aligning at 16 bytes here, not 32-bits. >> >>> .code 32 >>> 1:...