[llvm-dev] Linux/ARM: Segfault issue when we build clang sources including __thread variable using -O2 flag

[Geunsik Lim via llvm-commits]

> Yes, as I said, I made it up. The real code used .LCPI42_27 or
> .LCPI36_27or something (I forget), used different registers and had
> dozens of instructions in between. But those details don't matter so I
> simplified it.

Thank you for sharing the reason in more detail.
At first glance, it seems that the key difference is "bl
_ZNK7TypeKey10GetNumArgsEv(PLT)"

between -O1 and -O2 from the clsload.s file. Could you tell me one example
to understand
what it is problem?

* filename: debug-O0-to-O3-clsload.c-assembly-with-save-temps.tar.gz
  download:
https://onedrive.live.com/redir?resid=C93799B86B006829!176&authkey=!ACoaXTFQPkbQDoo&ithint=file%2cgz


-------------------------------- clsload.s: -O1
---------------------------------------

.Ltmp599:
.loc 64 442 122              @
/work/dotnet/arm-32/coreclr/src/vm/clsload.cpp:442:122
mov r0, r4
bl _ZNK7TypeKey10GetNumArgsEv(PLT)
ldr r1, .LCPI36_2
ldr r2, [sp, #20]

-------------------------------- clsload.s: -O2
---------------------------------------
.Ltmp2818:
@ BB#4:
@DEBUG_VALUE: LookupTypeHandleForTypeKeyInner:pKey <- R4
@DEBUG_VALUE: LookupTypeHandleForTypeKeyInner:fCheckUnderLock <- R5
ldr r1, .LCPI36_2
.loc 34 769 53 discriminator 5 @
/work/dotnet/arm-32/coreclr/src/vm/crossgen/../typehandle.h:769:53

On Wed, May 11, 2016 at 10:39 PM, Tim Northover <t.p.northover at gmail.com>
wrote:

> On 10 May 2016 at 22:11, Geunsik Lim <leemgs at gmail.com> wrote:
> >> 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).
>
> The key was reusing litpool entries that get added to PC. That's an
> extremely odd sequence and almost certainly never what you want to do.
> After that it was just stepping through LLVM to work out where things
> went wrong.
>
> > Actually, I could not find the same assembly code that you commented to
> > r268662  from clsload.s file.
>
> Yes, as I said, I made it up. The real code used .LCPI42_27 or
> .LCPI36_27or something (I forget), used different registers and had
> dozens of instructions in between. But those details don't matter so I
> simplified it.
>
> >> 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
>
> Yes,  libcoreclr.so isn't affected at -O1. You'd have to write C code
> specially designed to trigger the bug (or be otherwise unlucky).
>
> 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/20160512/6d3a8ad4/attachment.html>