Debugging jitted code

Debugging jitted code

[Jan Vrany]

Hi all, 

I'd like to debug jitted code using GDB and it's jit interface. 
The code is generated by LLVM's MCJIT the jitter generates DWARF
debug info using LLVM's DIBuilder. I'd expect GDB to make use of
this info, but all I can see is name of the jitted function. 
GDB seems not to be aware of all the rest such as filenames and 
line numbers. 

Below you may find more details - I just try to give as much
information as possible:

I run x86_64 Linux and compiled most recent GDB myself:
gdb --version
GNU gdb (GDB) 7.12.50.20160829-git
Copyright (C) 2016 Free Software Foundation, Inc.
...

I'm using most recent LLVM 4.0 compiled from SVN tree, 
if that matters. 

To me it looks like the in-memory object ELF file generated by 
LLVM is fine and contain all the DWARF info. I checked this
by breaking on '__jit_debug_register_code'. Then I used gdb's
dump command:

(gdb) p * JITCodeEntry
$1 = {next_entry = 0x13bbcc0, prev_entry = 0x0, symfile_addr =
0x1442850 "\177ELF\002\001\001", symfile_size = 2960}
(gdb) dump binary memory /tmp/m.o 0x1442850 (0x1442850 + 2960)

and the used objdump /tmp/m.o to look what's inside. Looks 
good to me:

jv@sao:~/Projects/gdb/sources1/gdb$ objdump -x /tmp/m.o 

/tmp/m.o:     file format elf64-x86-64
/tmp/m.o
architecture: i386:x86-64, flags 0x00000011:
HAS_RELOC, HAS_SYMS
start address 0x0000000000000000

Sections:
Idx Name          Size      VMA               LMA               File
off  Algn
  0
.text         000001e4  0000000028000210  0000000028000210  00000040  2
**4
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1
.data         00000008  00000000013ba788  00000000013ba788  00000228  2
**3
                  CONTENTS, ALLOC, LOAD, DATA
  2
.debug_str    0000009a  0000000000000000  0000000000000000  00000230  2
**0
                  CONTENTS, READONLY, DEBUGGING
  3
.debug_loc    00000000  0000000000000000  0000000000000000  000002ca  2
**0
                  CONTENTS, READONLY, DEBUGGING
  4 .debug_abbrev
00000010  0000000000000000  0000000000000000  000002ca  2**0
                  CONTENTS, READONLY, DEBUGGING
  5
.debug_info   0000001e  0000000000000000  0000000000000000  000002da  2
**0
                  CONTENTS, RELOC, READONLY, DEBUGGING
  6 .debug_ranges
00000000  0000000000000000  0000000000000000  000002f8  2**0
                  CONTENTS, READONLY, DEBUGGING
  7 .debug_macinfo
00000001  0000000000000000  0000000000000000  000002f8  2**0
                  CONTENTS, READONLY, DEBUGGING
  8 .note.GNU-stack
00000000  0000000000000000  0000000000000000  000002f9  2**0
                  CONTENTS, READONLY
  9
.eh_frame     00000040  00000000013df908  00000000013df908  00000300  2
**3
                  CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
 10
.debug_line   0000005e  0000000000000000  0000000000000000  00000340  2
**0
                  CONTENTS, RELOC, READONLY, DEBUGGING

...rest ommited...

0x28000210 is address of the beginning of generated 
machine code. 

By quick look at jit.c, jit_bfd_try_read_symtab(), line ~ 941
it looks that gdb only reads / considers .text, .data and .eh_frame
sections, ignoring the rest including those containing DWARD debug 
info. This confuses me a little, but I have a very little knowledge
of DWARF / GDB internals. 

I'd appreciate if anyone can shed a bit of a light into this. 
It'd be really cool if I can see source line numbers or even
print variable names for jitted code from GDB.

Thanks a lot! 

Best, Jan

Re: Debugging jitted code

[Jan Vrany]

Hi all, 

just for the record: the problem was, of course, in
my code. Due to an unspotted change in LLVM, there
was a missing DIE for the function itself (DW_TAG_Subprogram). 
Once fixed, it started to work as expected. 

Many thanks to Keith Seitz for his comment, it saved me a
lot of time! Thanks a lot!

Jan


On Mon, 2016-08-29 at 23:26 +0100, Jan Vrany wrote:
> Hi all, 
> 
> I'd like to debug jitted code using GDB and it's jit interface. 
> The code is generated by LLVM's MCJIT the jitter generates DWARF
> debug info using LLVM's DIBuilder. I'd expect GDB to make use of
> this info, but all I can see is name of the jitted function. 
> GDB seems not to be aware of all the rest such as filenames and 
> line numbers. 
> 
> Below you may find more details - I just try to give as much
> information as possible:
> 
> I run x86_64 Linux and compiled most recent GDB myself:
> gdb --version
> GNU gdb (GDB) 7.12.50.20160829-git
> Copyright (C) 2016 Free Software Foundation, Inc.
> ...
> 
> I'm using most recent LLVM 4.0 compiled from SVN tree, 
> if that matters. 
> 
> To me it looks like the in-memory object ELF file generated by 
> LLVM is fine and contain all the DWARF info. I checked this
> by breaking on '__jit_debug_register_code'. Then I used gdb's
> dump command:
> 
> (gdb) p * JITCodeEntry
> $1 = {next_entry = 0x13bbcc0, prev_entry = 0x0, symfile_addr =
> 0x1442850 "\177ELF\002\001\001", symfile_size = 2960}
> (gdb) dump binary memory /tmp/m.o 0x1442850 (0x1442850 + 2960)
> 
> and the used objdump /tmp/m.o to look what's inside. Looks 
> good to me:
> 
> jv@sao:~/Projects/gdb/sources1/gdb$ objdump -x /tmp/m.o 
> 
> /tmp/m.o:     file format elf64-x86-64
> /tmp/m.o
> architecture: i386:x86-64, flags 0x00000011:
> HAS_RELOC, HAS_SYMS
> start address 0x0000000000000000
> 
> Sections:
> Idx Name          Size      VMA               LMA               File
> off  Algn
>   0
> .text         000001e4  0000000028000210  0000000028000210  00000040 
>  2
> **4
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>   1
> .data         00000008  00000000013ba788  00000000013ba788  00000228 
>  2
> **3
>                   CONTENTS, ALLOC, LOAD, DATA
>   2
> .debug_str    0000009a  0000000000000000  0000000000000000  00000230 
>  2
> **0
>                   CONTENTS, READONLY, DEBUGGING
>   3
> .debug_loc    00000000  0000000000000000  0000000000000000  000002ca 
>  2
> **0
>                   CONTENTS, READONLY, DEBUGGING
>   4 .debug_abbrev
> 00000010  0000000000000000  0000000000000000  000002ca  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   5
> .debug_info   0000001e  0000000000000000  0000000000000000  000002da 
>  2
> **0
>                   CONTENTS, RELOC, READONLY, DEBUGGING
>   6 .debug_ranges
> 00000000  0000000000000000  0000000000000000  000002f8  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   7 .debug_macinfo
> 00000001  0000000000000000  0000000000000000  000002f8  2**0
>                   CONTENTS, READONLY, DEBUGGING
>   8 .note.GNU-stack
> 00000000  0000000000000000  0000000000000000  000002f9  2**0
>                   CONTENTS, READONLY
>   9
> .eh_frame     00000040  00000000013df908  00000000013df908  00000300 
>  2
> **3
>                   CONTENTS, ALLOC, LOAD, RELOC, READONLY, DATA
>  10
> .debug_line   0000005e  0000000000000000  0000000000000000  00000340 
>  2
> **0
>                   CONTENTS, RELOC, READONLY, DEBUGGING
> 
> ...rest ommited...
> 
> 0x28000210 is address of the beginning of generated 
> machine code. 
> 
> By quick look at jit.c, jit_bfd_try_read_symtab(), line ~ 941
> it looks that gdb only reads / considers .text, .data and .eh_frame
> sections, ignoring the rest including those containing DWARD debug 
> info. This confuses me a little, but I have a very little knowledge
> of DWARF / GDB internals. 
> 
> I'd appreciate if anyone can shed a bit of a light into this. 
> It'd be really cool if I can see source line numbers or even
> print variable names for jitted code from GDB.
> 
> Thanks a lot! 
> 
> Best, Jan
> 
> 
> 
> 
> 
> 
> 
>