Re: Debugging jitted code

[Jan Vrany <jan.vrany@fit.cvut.cz>]

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
> 
> 
> 
> 
> 
> 
> 
>