search for: blx

...to Thumb1InstrInfo. > For the following case: > > void f(int x, int y, int z) > { > void bar(int, int, int); > > bar(x, y, z); > bar(x, z, y); > bar(y, x, z); > bar(y, y, x); > } > > it calls foldMemoryOperand twice, and thus converts two calls from blx to bl. > callMI->dump() shows the function name "bar" correctly, however in > generated assembly call to bar is garbled: > (compiled with -Oz --target=arm-linux-gnueabi -marcha=armv6-m): > > add r7, sp, #16 > mov r6, r2 > mov r5,...

Hi Mayur, > On 24 Nov 2014, at 07:00, MAYUR PANDEY <mayur.p at samsung.com> wrote: > In the assembly generated with O0, we are getting the "blx" instruction whereas with O1 we get "bx" (in 3.4.2 we used to get "blx" for both O0 and O1). > > Is this because of this patch: [llvm] r214959 - ARM: do not generate BLX instructions on Cortex-M CPUs Isn't this just the usual tail call optimisations kicking i...

...t;+0>: push {r11, lr} 0x401e41e0 <+4>: mov r11, sp 0x401e41e4 <+8>: sub sp, sp, #8 0x401e41e8 <+12>: ldr r0, [r0] 0x401e41ec <+16>: str r0, [sp, #4] 0x401e41f0 <+20>: mov r0, r1 0x401e41f4 <+24>: ldr r1, [sp, #4] => 0x401e41f8 <+28>: blx r1 0x401e41fc <+32>: and r0, r0, #1 0x401e4200 <+36>: and r0, r0, #1 0x401e4204 <+40>: mov sp, r11 0x401e4208 <+44>: pop {r11, lr} 0x401e420c <+48>: bx lr blx instruction is available from ARM architecture v5 and above… After lot of investigations I fou...

...lized at all, but upon closer examination I think it may actually be initialized from a program counter-relative 32-bit .long constant immediately following my method's code. .loc 1 388 3 ldr r0, [r5] ldr r1, [r4, r0] adds r1, #1 str r1, [r4, r0] .loc 1 390 64 mov r0, r4 ldr r1, [r6] blx _objc_msgSend vmov s0, r0 vmul.f32 d0, d0, d8 vcvt.u32.f32 d0, d0 vmov r0, s0 Ltmp272: .loc 1 392 9 cmp.w r0, #4000 Ltmp273: .loc 1 393 13 it hs blxhs _usleep cmp.w *looks* like a 16-bit comparison with an immediate constant, but in reality the constant is twelve bits. The ARM and Thumb...

Hi Tim, You seem to be working around BLX support on ARM, and this linker error has cropped up on our buildbot: http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/3526 llvm/tools/clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp: (.text._ZN5clang4ento24ProgramStatePartialTraitIN4llvm12ImmutableMapIPKNS0_7SymExprE...

...onwards the J1 and J2 fields of the instruction form part of the immediate. Technically, I think a linker is allowed to do what you've done so it's probably good enough for now as long as we put an assertion into the code that RelType isn't too big. Second, I don't think it handles BLX correctly. When used on a BLX the instruction is assumed to be at "Align(PC, 4)" rather than just "PC". I *think* this means that if the BLX instruction was at an address "== 2 (mod 4)" then your code would set the 'H' bit and create an undefined instruction....

Hello, here is a patch to add Thumb call relocation to the dynamic linker. I would be happy if you could commit it to the SVN. Thank you, Jonas -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130524/069287d6/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed...

On 18 May 2016 at 15:12, Tim Northover <t.p.northover at gmail.com> wrote: > I don't suppose you could grab a -save-temps output for MallocChecker.cpp? Not from the bot any more. I didn't expect this to be a heisenbug. And I'm having trouble replicating it on my other machine. > I think we only produce R_ARM_THM_JUMP24 for tail calls. The veneer is > then needed if a

On 18 May 2016 at 17:32, Tim Northover <t.p.northover at gmail.com> wrote: > That's the thing: this shouldn't have changed at all recently. We emit > "b.w dest" with an R_ARM_THM_JUMP24 reloc. The linker then needs a > veneer if dest is out of range or an ARM function. Peter has just reminded me the fact that the relocation itself is in libstdc++, not on the

I noticed that LLD doesn’t preserve the symbol type for a defsym directive. For example: $ cat f.c void f() {} $ clang -c f.c $ ld.lld -shared --defsym=g=f f.o $ objdump -T a.out DYNAMIC SYMBOL TABLE: 00000000000012a0 g DF .text 0000000000000006 f 00000000000012a0 g D .text 0000000000000000 g f is marked as a function symbol, but g is not. I recognize this is hard to do in the general

...lvm-dev > <llvm-dev at lists.llvm.org> wrote: > > But libc code is in ARM mode: > > That's very bad, because Cortex-M doesn't support ARM mode. I think > your libc is broken. > > > As you can see, the call to srand is just a bl (Branch with Link), not a > blx > > (Branch with Link and Exchange instruction set), so I think something is > > going wrong here. > > Yes, Cortex-M has no blx instruction. > > > Can anyone kindly give me some pointers on how to debug this? Or at least > > tell me whether this is a bug? > >...

Hi, I have attached WIP patch for adding foldMemoryOperand to Thumb1InstrInfo. For the following case: void f(int x, int y, int z) { void bar(int, int, int); bar(x, y, z); bar(x, z, y); bar(y, x, z); bar(y, y, x); } it calls foldMemoryOperand twice, and thus converts two calls from blx to bl. callMI->dump() shows the function name "bar" correctly, however in generated assembly call to bar is garbled: (compiled with -Oz --target=arm-linux-gnueabi -marcha=armv6-m): add r7, sp, #16 mov r6, r2 mov r5, r1 mov r4, r0...

splited patches and test cases mc-elf-thumbfunction-bit.diff: for 1 mc-elf-arm-backend-bl-blx-sign-bit.diff: for 2. mc-elf-thumb-bl-blx-relocation-table-entry.diff: for 3. mc-elf-cpu-xscale-attributes.diff: for 4. elf-thumbfunc.s: test case for 1 elf-thumbfunc-reloc.ll: test case for 2 and 3 elf-xscale-attribute.ll: test case for 4 On Fri, May 13, 2011 at 1:42 PM, Koan-Sin Tan <koansin...

...March 2018 at 15:06, Son Tuan VU via llvm-dev <llvm-dev at lists.llvm.org> wrote: > But libc code is in ARM mode: That's very bad, because Cortex-M doesn't support ARM mode. I think your libc is broken. > As you can see, the call to srand is just a bl (Branch with Link), not a blx > (Branch with Link and Exchange instruction set), so I think something is > going wrong here. Yes, Cortex-M has no blx instruction. > Can anyone kindly give me some pointers on how to debug this? Or at least > tell me whether this is a bug? You don't mention how you build libc,...

On 11-05-16 09:21 AM, Koan-Sin Tan wrote: > splited patches and test cases > > mc-elf-thumbfunction-bit.diff: for 1 > mc-elf-arm-backend-bl-blx-sign-bit.diff: for 2. > mc-elf-thumb-bl-blx-relocation-table-entry.diff: for 3. > mc-elf-cpu-xscale-attributes.diff: for 4. > > elf-thumbfunc.s: test case for 1 > elf-thumbfunc-reloc.ll: test case for 2 and 3 > elf-xscale-attribute.ll: test case for 4 > I have checked in the f...

...2] ; 91f0 <srand+0x18> 1566 91e0: e5933000 ldr r3, [r3] 1567 91e4: e58300a8 str r0, [r3, #168] ; 0xa8 1568 91e8: e58320ac str r2, [r3, #172] ; 0xac 1569 91ec: e12fff1e bx lr As you can see, the call to *srand* is just a *bl (Branch with Link)*, not a *blx (Branch with Link and Exchange instruction set)*, so I think something is going wrong here. Indeed, when using a binary analysis tool to simulate this code, it cannot executes correctly *srand* because it decodes instruction in Thumb mode. Surprisingly, compiling this code with *arm-none-eabi-gcc*...

...401e41e0 <+4>: mov r11, sp > 0x401e41e4 <+8>: sub sp, sp, #8 > 0x401e41e8 <+12>: ldr r0, [r0] > 0x401e41ec <+16>: str r0, [sp, #4] > 0x401e41f0 <+20>: mov r0, r1 > 0x401e41f4 <+24>: ldr r1, [sp, #4] > => 0x401e41f8 <+28>: blx r1 > 0x401e41fc <+32>: and r0, r0, #1 > 0x401e4200 <+36>: and r0, r0, #1 > 0x401e4204 <+40>: mov sp, r11 > 0x401e4208 <+44>: pop {r11, lr} > 0x401e420c <+48>: bx lr > blx instruction is available from ARM architecture v5 and above… >...

...s.llvm.org> wrote: >> > But libc code is in ARM mode: >> >> That's very bad, because Cortex-M doesn't support ARM mode. I think >> your libc is broken. >> >> > As you can see, the call to srand is just a bl (Branch with Link), not a >> > blx >> > (Branch with Link and Exchange instruction set), so I think something is >> > going wrong here. >> >> Yes, Cortex-M has no blx instruction. >> >> > Can anyone kindly give me some pointers on how to debug this? Or at >> > least >> >...

...than our callee-saved registers * Therefore something needs to be spilt * The function address can be rematerialized, so we spill that and insert and LDR before each call If we didn't have this spilling happening (e.g. if the function had one less argument) then the code size of using BL vs BLX * BL: 3*4-byte BL = 12 bytes * BX: 3*2-byte BX + 1*2-byte LDR + 4-byte litpool = 12 bytes (So maybe even not considering spilling, LowerCall should be adjusted to do this for functions called 4 or more times) When we have to spill, if we compare spilling the functions address vs spilling an argu...

Hi, Compiling attached test-case, which is reduced version of of uECC_shared_secret from tinycrypt library [1], with --target=arm-linux-gnueabi -march=armv6-m -Oz -S results in reloading of register holding function's address before every call to blx: ldr r3, .LCPI0_0 blx r3 mov r0, r6 mov r1, r5 mov r2, r4 ldr r3, .LCPI0_0 blx r3 ldr r3, .LCPI0_0 mov r0, r6 mov r1, r5 mov r2, r4 blx r3 .LCPI...