[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag
Geunsik Lim via llvm-commits
llvm-commits at lists.llvm.org
Tue May 10 22:11:40 PDT 2016
> we cannot combine the 2 ldr instructions and litpools because they get added to
> a different pc to form the correct address.
I wonder how we can figure out the reason such as the above statement
from the libcoreclr.so (or clsload.s).
Actually, I could not find the same assembly code that you commented
to r268662 from clsload.s file.
For example,
--------------- with -O1 of clang :
clsload-assembly-O1/clsload.s-----------------------------------------------------------------------------------
219 .Ltmp11:
220 @DEBUG_VALUE:
ComputeLoaderModuleWorker:pFirstNonSystemSharedModule <- R0
221 mov r11, r0
222 .Ltmp12:
223 @DEBUG_VALUE:
ComputeLoaderModuleWorker:pFirstNonSystemSharedModule <- R11
224 @DEBUG_VALUE: ComputeLoaderModuleWorker:pDefinitionModule <- R11
225 ldr r0, .LCPI0_0
226 ldr r5, .LCPI0_1
227 mov r4, r2
228 .Ltmp13:
229 @DEBUG_VALUE: ComputeLoaderModuleWorker:classInst <- R4
230 .LPC0_0:
231 add r0, pc
232 mov r6, r3
233 .Ltmp14:
234 @DEBUG_VALUE: ComputeLoaderModuleWorker:methodInst <- R6
235 mov r9, r1
236 .Ltmp15:
237 @DEBUG_VALUE: ComputeLoaderModuleWorker:token <- R9
238 ldr r0, [r5, r0]
239 ldr r0, [r0]
240 str r0, [sp, #88]
241 .loc 64 98 9 @
/work/dotnet/arm-32/coreclr/src/vm/clsload.cpp:98 :9
--------------- with -O2 of clang :
clsload-assembly-O2/clsload.s-------------------------------------
219 .Ltmp11:
220 @DEBUG_VALUE:
ComputeLoaderModuleWorker:pFirstNonSystemSharedModule <- R0
221 mov r9, r0
222 .Ltmp12:
223 @DEBUG_VALUE:
ComputeLoaderModuleWorker:pFirstNonSystemSharedModule <- R9
224 @DEBUG_VALUE: ComputeLoaderModuleWorker:pDefinitionModule <-
R9
225 ldr.w r0, .LCPI0_0
226 .loc 34 738 50 discriminator 2 @
/work/dotnet/arm-32/coreclr/src/vm/crossg en/../typehandle.h:738:50
227 .Ltmp13:
228 ldr.w r8, .LCPI0_1
229 mov r6, r2
230 .Ltmp14:
231 @DEBUG_VALUE: ComputeLoaderModuleWorker:classInst <- R6
232 .LPC0_0:
233 add r0, pc
234 mov r5, r3
235 .Ltmp15:
236 @DEBUG_VALUE: ComputeLoaderModuleWorker:methodInst <- R5
237 mov r4, r1
> The inliner was needed in this case because most TLS accesses were hidden
away in GetThread.
> You could write C code that would fail at -O1 if you tried.
It's strange. I can normally run C# console applications with
libcoreclr.so that is built by -O1 such as -O0
---------------------------[ libcoreclr.so: with -O0
]----------------------------------
185920 000a221c <GetThread>:
185921 a221c: b580 push {r7, lr}
185922 a221e: 466f mov r7, sp
185923 a2220: e7ff b.n a2222 <GetThread+0x6>
185924 a2222: 2000 movs r0, #0
185925 a2224: 2800 cmp r0, #0
185926 a2226: d106 bne.n a2236 <GetThread+0x1a>
185927 a2228: e7ff b.n a222a <GetThread+0xe>
185928 a222a: 4803 ldr r0, [pc, #12] ; (a2238
<GetThread+0x1c>)
185929 a222c: 4478 add r0, pc
185930 a222e: f795 eca0 blx 37b70 <__tls_get_addr at plt>
185931 a2232: 6800 ldr r0, [r0, #0]
185932 a2234: bd80 pop {r7, pc}
185933 a2236: defe .short 0xdefe
185934 a2238: 00a4f908 .word 0x00a4f908
185935
---------------------------[ libcoreclr.so: with -O1
]----------------------------------
73533 00066b10 <GetThread>:
73534 66b10: b580 push {r7, lr}
73535 66b12: 466f mov r7, sp
73536 66b14: 4802 ldr r0, [pc, #8] ; (66b20
<GetThread+0x10>)
73537 66b16: 4478 add r0, pc
73538 66b18: f7d0 ece0 blx 374dc <__tls_get_addr at plt>
73539 66b1c: 6800 ldr r0, [r0, #0]
73540 66b1e: bd80 pop {r7, pc}
73541 66b20: 0071bdf6 .word 0x0071bdf6
73542
---------------------------[ libcoreclr.so: with -O2
]----------------------------------
572341 001a37e8 <GetThread>:
572342 1a37e8: b580 push {r7, lr}
572343 1a37ea: 466f mov r7, sp
572344 1a37ec: 4802 ldr r0, [pc, #8] ; (1a37f8
<GetThread+0x10>)
572345 1a37ee: 4478 add r0, pc
572346 1a37f0: f68d eee4 blx 315bc <__tls_get_addr at plt>
572347 1a37f4: 6800 ldr r0, [r0, #0]
572348 1a37f6: bd80 pop {r7, pc}
572349 1a37f8: 0079a2be .word 0x0079a2be
572350
---------------------------[ libcoreclr.so: with -O3
]----------------------------------
592749 001b12d8 <GetThread>:
592750 1b12d8: b580 push {r7, lr}
592751 1b12da: 466f mov r7, sp
592752 1b12dc: 4802 ldr r0, [pc, #8] ; (1b12e8
<GetThread+0x10>)
592753 1b12de: 4478 add r0, pc
592754 1b12e0: f680 e950 blx 31584 <__tls_get_addr at plt>
592755 1b12e4: 6800 ldr r0, [r0, #0]
592756 1b12e6: bd80 pop {r7, pc}
592757 1b12e8: 007d47ca .word 0x007d47ca
592758
On Wed, May 11, 2016 at 11:32 AM, Tim Northover <t.p.northover at gmail.com>
wrote:
> On 10 May 2016 at 19:16, Geunsik Lim <leemgs at gmail.com> wrote:
> >> Given something like:
> >>
> >> ldr r0, .LCPI0_0 (== pc-rel var)
> >> add r0, pc
> >>
> >> ldr r1, .LCPI0_1 (== pc-rel var)
> >> add r1, pc
> >>
> >
> > Where can we get the above assembly code?
> > For example, from clsload.s with "save-temps" flag?
>
> Clang's -save-temps output is pretty close to this (or alternatively
> "clang -S" if you don't want the other files) but I actually just made
> up these examples to illustrate what was happening.
>
> Cheers.
>
> Tim.
>
--
http://leemgs.fedorapeople.org
Don't try to avoid pain if you fail.
If you decided to face the challenges in life,
you can gain a lot by giving your best.
Cheolsang Jeong's Book & life
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20160511/ab1fdd7e/attachment-0001.html>
More information about the llvm-commits
mailing list