This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Debugging jitted code
- From: Jan Vrany <jan dot vrany at fit dot cvut dot cz>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Mon, 29 Aug 2016 23:26:19 +0100
- Subject: Debugging jitted code
- Authentication-results: sourceware.org; auth=none
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