This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Debugging jitted code
- From: Jan Vrany <jan dot vrany at fit dot cvut dot cz>
- To: gdb at sourceware dot org
- Date: Tue, 30 Aug 2016 20:50:54 +0100
- Subject: Re: Debugging jitted code
- Authentication-results: sourceware.org; auth=none
- References: <1472509579.13311.23.camel@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
>
>
>
>
>
>
>
>