Why -jit-emit-debug doesn't work with gdb-7.1 ?

I have followed http://llvm.org/docs/DebuggingJITedCode.html, used the latest release gdb-7.1 (from March 18, 2010) and got this stack:

(gdb) bt
#0 0x35532156 in ?? ()
#1 0x355320f8 in ?? ()
#2 0x35532098 in ?? ()
#3 0x3553202e in ?? ()
#4 0x34a5661a in ?? ()
#5 0x349d9bd9 in ?? ()
#6 0x08052cd9 in main (argc=4, argv=0xbfbfe264, envp=0xbfbfe278) at /tmp/llvm-svn/llvm/tools/lli/lli.cpp:234

Did they not include llvm interface into 7.1 release?

On the side note: is option -disable-fp-elim also required for gdb? I am getting different stack depths in gdb with and without it.

Yuri

I have followed Debugging JIT-ed Code — LLVM 18.0.0git documentation, used the
latest release gdb-7.1 (from March 18, 2010) and got this stack:

(gdb) bt
#0 0x35532156 in ?? ()
#1 0x355320f8 in ?? ()
#2 0x35532098 in ?? ()
#3 0x3553202e in ?? ()
#4 0x34a5661a in ?? ()
#5 0x349d9bd9 in ?? ()
#6 0x08052cd9 in main (argc=4, argv=0xbfbfe264, envp=0xbfbfe278) at
/tmp/llvm-svn/llvm/tools/lli/lli.cpp:234

Did they not include llvm interface into 7.1 release?

Yes, I have some version of 7.1 installed on my workstation and it works for me.

With this source file t.c:

#include <stdio.h>
#include <stdlib.h>
void baz() {
  printf("Hello, World!\n");
  abort();
}
void bar() {
  baz();
}
void foo() {
  bar();
}
int main(int argc, char **argv) {
  foo();
  return 0;
}

Compiled like so:

[rnk@tamalpais llvm]$ Debug/bin/clang -fexceptions t.c -c -emit-llvm -o t.bc

-fexceptions is important when compiling C code, because otherwise the
functions are annotated nounwind, which avoids generating .eh_frame
dwarf. gdb uses the exception handling dwarf to unwind the stack. So
long as your frontend doesn't add nounwind it's not a problem.

[rnk@tamalpais llvm]$ gdb --args Debug/bin/lli t.bc
GNU gdb (GDB) 7.1-gg5
...
Reading symbols from /home/rnk/llvm/Debug/bin/lli...done.
(gdb) run
Starting program: /home/rnk/llvm/Debug/bin/lli t.bc
warning: no loadable sections found in added symbol-file
/usr/lib/debug/lib/ld-2.7.so
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Hello, World!

Program received signal SIGABRT, Aborted.
0x00007ffff4e7d095 in raise () from /lib/libc.so.6
(gdb) bt
#0 0x00007ffff4e7d095 in raise () from /lib/libc.so.6
#1 0x00007ffff4e7eaf0 in abort () from /lib/libc.so.6
#2 0x00007ffff7f5e198 in baz ()
#3 0x00007ffff7f5e110 in bar ()
#4 0x00007ffff7f5e0a0 in foo ()
#5 0x00007ffff7f5e031 in main ()
#6 0x00007ffff6d79a89 in llvm::JIT::runFunction (this=0x647c10, F=0x643040,
    ArgValues=std::vector of length 2, capacity 2 = {...}) at JIT.cpp:439
#7 0x00007ffff6d03b1b in llvm::ExecutionEngine::runFunctionAsMain
(this=0x647c10, Fn=0x643040,
    argv=std::vector of length 1, capacity 1 = {...},
envp=0x7fffffffe520) at ExecutionEngine.cpp:423
#8 0x000000000040d42b in main (argc=2, argv=0x7fffffffe508,
envp=0x7fffffffe520) at lli.cpp:234
(gdb)

In a debug build, you shouldn't have to pass -jit-emit-debug, since
it's on by default. I would have tested with a release build, but I
won't have one until ~15min from now. :slight_smile:

On the side note: is option -disable-fp-elim also required for gdb? I am
getting different stack depths in gdb with and without it.

No, it shouldn't be.

Are you giving your functions names?

Reid

I repeted what you did step by step and it still doesn't work for me, see log below.
Two differences: I am on FreeBSD and it's 32 bit. It's svn revision 105825. Plus I have few unrelated patched applied to it which shouldn't matter.

Yuri

$ lli --version
Low Level Virtual Machine (http://llvm.org/):
   llvm version 2.8svn
   DEBUG build with assertions.
   Built Jun 21 2010 (09:46:06).
   Host: i386-unknown-freebsd8.1
   Host CPU: corei7

   Registered Targets:
     x86 - 32-bit X86: Pentium-Pro and above
     x86-64 - 64-bit X86: EM64T and AMD64
$ clang -fexceptions t.c -c -emit-llvm -o t.bc
$ gdb --args lli -jit-emit-debug t.bc
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html&gt;
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-unknown-freebsd8.1".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/&gt;\.\.\.
Reading symbols from /usr/local/llvm/svn-r105825.dbg/bin/lli...done.
(gdb) run
Starting program: /usr/local/llvm/svn-r105825.dbg/bin/lli -jit-emit-debug t.bc
Hello, World!

Program received signal SIGABRT, Aborted.
0x354fa0f7 in ?? ()
(gdb) bt
#0 0x354fa0f7 in ?? ()
#1 0x354f8c2a in ?? ()
#2 0x35531134 in ?? ()
#3 0x349d9b05 in ?? ()
#4 0x08052cd9 in main (argc=3, argv=0xbfbfe238, envp=0xbfbfe248) at /tmp/llvm-svn/llvm/tools/lli/lli.cpp:234

Since FreeBSD is an ELF target, this should work fine. I've also
tested that this works in 32-bit by building gdb and llvm in 32-bit
mode and testing this stuff while running on a 64-bit OS.

I would try setting a breakpoint in gdb on
'llvm::JITDebugRegisterer::RegisterFunction' to see that it is being
called, and that getELFWriterInfo returns something. If that function
actually installs the code entry, then it's a gdb problem.

Reid

I am on FreeBSD and gdb-7.1 seems to be broken. It fails to set breakpoints in shared libs. using symbol-file causes this message:

(gdb) symbol-file /usr/local/llvm/svn-r105825.dbg/lib/libLLVM-2.8svn.so
Load new symbol table from
"/usr/local/llvm/svn-r105825.dbg/lib/libLLVM-2.8svn.so"? (y or n) y
Reading symbols from /usr/local/llvm/svn-r105825.dbg/lib/libLLVM-2.8svn.so...done.
Unable to read JIT descriptor from remote memory!

Googling this message leads back to your name :slight_smile: Do you know why might it fail to load JIT descriptor?

I filed gdb PR: 11737 – Can't set breakpoint in the statically linked shared library on FreeBSD-8.0

Yuri

One thing you could do as a temporary work around is to link with LLVM
statically. There's already an open bug where if the JIT is in a
shared library, then you cannot run the program twice under gdb
without restarting gdb, which is really annoying.

This affects me, and I do intend to fix it eventually. I'm not sure
if it's the same as your problem though.

Reid

Looks like this is the same problem.

Yuri

Did you have a chance to fix this issue with gdb failing to debug libLLVM-2.8svn.so as a shared lib?
I keep hitting this issue. Older gdb for some reason doesn't see llvm::* types which makes debugging difficult. And I can't really link with LLVM statically.

Yuri

No. This isn't really work related for me now, so I haven't tried
tackling it on my workstation. For the summer I only have access to
my MacBook, which isn't an ELF target. Recently I've had more spare
time to push these kinds of patches to random projects through, so I
might get to it next week.

Reid

I don't know what is going on with gdb and llvm, but I tried the upcoming gdb-7.3 and the message "Unable to read JIT descriptor from remote memory!" is back when llvm::JITEmitDebugInfo is set and libLLVM-3.0.so is loaded dynamically.

gdb-7.1 was broken, gdb-7.2 works, now gdb-7.3 code is broken again.

Yuri