Get full stack traces from LLVM JITed code

[GoogleCodeExporter]

Steps to reproduce:
1. Modify a C function in Python that you know will be called from LLVM so
that it will segfault.  (printf("%d\n", *((int*)NULL));)
2. Build Python --with-pydebug.
3. Load up the binary in GDB.
4. Run a python script that will call the bad function with -L2.
5. Examine the backtrace.

The stack trace should show your C function and maybe some frames above it,
and then the heap address of some LLVM generated code with no name for it.
 If you're lucky, eventually the trace will get past there and make it back
down to main.  If you're unlucky, you get nothing.

As a work around, you can set the environment variable
PYTHONLLVMFLAGS="--disable-fp-elim" to your python binary, and that should
give you a full stack trace that is only missing information for LLVM
generated code.  Eventually we'd like to enable this by default for debug
builds, but right now there's no easy way to toggle that option.  The right
thing to do would probably be to submit a patch to LLVM so we can toggle
that option.

Original issue reported on code.google.com by reid.kle...@gmail.com on 8 Jun 2009 at 5:50

[GoogleCodeExporter]

Can we automate the workaround somehow? Can we forcibly add this to the list of
command-line flags LLVM is parsing in 
Python/global_llvm_data.cc:_PyLlvm_Init(), or
is there an LLVM option we can toggle programmatically?

Original comment by collinw on 8 Jun 2009 at 6:06

• Added labels: Release-2009Q2

[GoogleCodeExporter]

Yes, you can get it passed in that way, but the way the code is written right 
now
makes it tricky.  We could read the env variable, append " --disable-fp-elim" 
to it,
then write it back to the env variable, or we could read the variable, properly 
split
it on spaces (blech), and pass that off to ParseCommandLineOptions.

The code to toggle that option at runtime isn't in LLVM right now, and Jeff 
says that
if you just go in there and flip the value it has some assertions that will 
complain
that the value was set twice.

Original comment by reid.kle...@gmail.com on 8 Jun 2009 at 6:14

[GoogleCodeExporter]

Original comment by collinw on 10 Jun 2009 at 3:11

[GoogleCodeExporter]

Original comment by collinw on 13 Jul 2009 at 5:50

• Added labels: Release-2009Q3

[GoogleCodeExporter]

I committed the LLVM side of the GDB JIT debugging interface in r82418 of LLVM. 
 We
don't have to update LLVM right away to start using it, because I think right 
now
unladen builds against LLVM TOT.  All you have to do is install GDB from CVS 
and link
unladen against LLVM TOT.

I'm leaving this bug open, and we can close it when we feel like updating LLVM 
in
trunk again, since it's kind of a pain.

Original comment by reid.kle...@gmail.com on 21 Sep 2009 at 12:01

[GoogleCodeExporter]

Great, thanks Reid! Do you have a test script (shell will do) that we can use 
to make 
sure the gdb/LLVM integration is working smoothly, or should I just stick a 
null 
pointer dereference somewhere?

Original comment by collinw on 21 Sep 2009 at 9:06

[GoogleCodeExporter]

I just put a breakpoint on PyObject_Print and write a script like so:

def foo(): bar()
def bar(): baz()
def baz(): print 'Hello, World!'
foo()

... and run it with -S and -j always.  The backtrace for unladen should show 4 
JITed
frames starting with #u#, one for the module and one for each function.  You 
could
make an integration test out of this, but you'd have to guard it on the version 
of GDB.

Original comment by reid.kle...@gmail.com on 21 Sep 2009 at 11:48

[GoogleCodeExporter]

Closed, since Jeff pulled the latest changes in from LLVM.  Apparently GDB 7.0 
is
coming around the corner, so this should work out of the box for everyone in 
less
than a year.

Original comment by reid.kle...@gmail.com on 24 Sep 2009 at 5:27

• Changed state: Fixed

[GoogleCodeExporter]

I actually need to check in the gdb test before this is fully closed.

Original comment by jyass...@gmail.com on 24 Sep 2009 at 6:50

• Changed state: Started

[GoogleCodeExporter]

Tested with r841.

Original comment by jyass...@gmail.com on 29 Sep 2009 at 12:22

• Changed state: Fixed