llvm dev - Jun 2010 - [LLVMdev] Why would -disable-fp-elim cause SEGV in JIT, when without it code works fine?

I have this situation when the same code SEGVs in JIT with option 
-disable-fp-elim and works fine without it.
How can this possibly happen?
Is it possible that there is a bug in JIT that stack isn't properly 
lowered for local variables when prologs are present?
Or maybe JIT can accidentally use ebp for some values when it's supposed 
to be only used by frame pointer value.

Stack (see below) in gdb looks strange -- there are some very low values 
or zeros there.

How well code with prologs is tested? Does llvm (llvm-g++/clang) 
normally generate code only without prologs?

r105825

Yuri

(gdb) bt
#0  0x5e95c0c6 in ?? ()
#1  0x00000019 in ?? ()
#2  0x5e98a28f in ?? ()
#3  0x0a5a00bc in ?? ()
#4  0x09cae924 in ?? ()
#5  0x00000006 in ?? ()
#6  0x5e98b895 in ?? ()
#7  0x0a5a00bc in ?? ()
#8  0x09cae924 in ?? ()
#9  0x0a29a32c in ?? ()
#10 0x0a29a32c in ?? ()
#11 0x09c40df0 in ?? ()
#12 0x50aa88e0 in ?? ()
#13 0x50aa88c0 in ?? ()
#14 0xbfbfa824 in ?? ()
#15 0x348405e8 in dladdr () from /libexec/ld-elf.so.1
#16 0x5e900d76 in ?? ()
#17 0x0a5a00bc in ?? ()
#18 0x09cae90c in ?? ()
#19 0x00000000 in ?? ()
#20 0x0902df80 in ?? ()
#21 0x5e7210ac in ?? ()
#22 0x00000000 in ?? ()
#23 0x00000000 in ?? ()
#24 0x64616572 in ?? ()
#25 0x09caec9c in ?? ()
<skipped>

You said this is on 32-bit x86?  My understanding is that in that
case, gdb will use ebp/esp to unwind the stack and doesn't need dwarf.
 It may have different behavior on FreeBSD if frame pointers are
normally omitted on that platform.  gdb ignores them on Linux x86_64
because they are generally omitted.

This might actually be the best explanation for your symptoms, since
this is what a gdb backtrace looks like when it is trying to use dwarf
to unwind the stack but there is none available.

Have you been able to succeed at linking statically with LLVM to get
the gdb JIT interface working?  That should fix this, and give you the
ability to disas JITed functions.

Another useful technique is to use x/20i <funcaddr> to look at the
assembly of the JITed function to see what is wrong with it.  You
should be able to get the function addresses from your addr2line
output.  As a last resort, you can unwind the stack yourself, so long
as all the code you're running has frame pointers enabled.

Reid

On Wed, Jun 23, 2010 at 1:26 AM, Yuri <yuri at rawbw.com>
wrote:
> I have this situation when the same code SEGVs in JIT with option
> -disable-fp-elim and works fine without it.
> How can this possibly happen?
> Is it possible that there is a bug in JIT that stack isn't properly
> lowered for local variables when prologs are present?
> Or maybe JIT can accidentally use ebp for some values when it's
supposed
> to be only used by frame pointer value.
>
> Stack (see below) in gdb looks strange -- there are some very low values
> or zeros there.
>
> How well code with prologs is tested? Does llvm (llvm-g++/clang)
> normally generate code only without prologs?
>
> r105825
>
> Yuri
>
> (gdb) bt
> #0  0x5e95c0c6 in ?? ()
> #1  0x00000019 in ?? ()
> #2  0x5e98a28f in ?? ()
> #3  0x0a5a00bc in ?? ()
> #4  0x09cae924 in ?? ()
> #5  0x00000006 in ?? ()
> #6  0x5e98b895 in ?? ()
> #7  0x0a5a00bc in ?? ()
> #8  0x09cae924 in ?? ()
> #9  0x0a29a32c in ?? ()
> #10 0x0a29a32c in ?? ()
> #11 0x09c40df0 in ?? ()
> #12 0x50aa88e0 in ?? ()
> #13 0x50aa88c0 in ?? ()
> #14 0xbfbfa824 in ?? ()
> #15 0x348405e8 in dladdr () from /libexec/ld-elf.so.1
> #16 0x5e900d76 in ?? ()
> #17 0x0a5a00bc in ?? ()
> #18 0x09cae90c in ?? ()
> #19 0x00000000 in ?? ()
> #20 0x0902df80 in ?? ()
> #21 0x5e7210ac in ?? ()
> #22 0x00000000 in ?? ()
> #23 0x00000000 in ?? ()
> #24 0x64616572 in ?? ()
> #25 0x09caec9c in ?? ()
> <skipped>
>
> _______________________________________________
> LLVM Developers mailing list
> LLVMdev at cs.uiuc.edu         http://llvm.cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>

On 06/23/2010 10:24, Reid Kleckner wrote:
> You said this is on 32-bit x86?  My understanding is that in that
> case, gdb will use ebp/esp to unwind the stack and doesn't need dwarf.
>   It may have different behavior on FreeBSD if frame pointers are
> normally omitted on that platform.  gdb ignores them on Linux x86_64
> because they are generally omitted.
>
> This might actually be the best explanation for your symptoms, since
> this is what a gdb backtrace looks like when it is trying to use dwarf
> to unwind the stack but there is none available.
>
> Have you been able to succeed at linking statically with LLVM to get
> the gdb JIT interface working?  That should fix this, and give you the
> ability to disas JITed functions.
>
> Another useful technique is to use x/20i<funcaddr>  to look at the
> assembly of the JITed function to see what is wrong with it.  You
> should be able to get the function addresses from your addr2line
> output.  As a last resort, you can unwind the stack yourself, so long
> as all the code you're running has frame pointers enabled.
>
> Reid

I think there is some bug in indirectbr instruction. It actually doesn't 
work in JIT in the current trunk, but I submitted a patch some time ago 
that implements it. Someone suggested that I should eliminate code 
incapsulation breach, but this is besides the point here.

Once this patch applied, JIT supports address of label for instruction. 
It works, except in one large case. In this case I spotted the entry in 
one table of labels that contains pointer to invalid code. 
-print-machine-code prints assembly that looks correct, but the printout 
is missing memory location information: where each line is laid in memory.

Yuri
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: llvm-patch-address-of-label.txt
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20100623/abfef465/attachment.txt>