From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7532 invoked by alias); 29 Aug 2016 22:26:45 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 7519 invoked by uid 89); 29 Aug 2016 22:26:44 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=off, by, mo, 002 X-HELO: relay.fit.cvut.cz Received: from relay.fit.cvut.cz (HELO relay.fit.cvut.cz) (147.32.232.237) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 29 Aug 2016 22:26:40 +0000 Received: from imap.fit.cvut.cz (imap.fit.cvut.cz [IPv6:2001:718:2:2901:0:0:0:238]) by relay.fit.cvut.cz (8.15.2/8.15.2) with ESMTPS id u7TMQMNF060160 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK) for ; Tue, 30 Aug 2016 00:26:23 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Received: from [IPv6:2a02:c7d:2fc5:bf00:6267:20ff:fee4:3e2c] ([IPv6:2a02:c7d:2fc5:bf00:6267:20ff:fee4:3e2c]) (authenticated bits=0 as user vranyj1) by imap.fit.cvut.cz (8.15.2/8.15.2) with ESMTPSA id u7TMQLHJ027663 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 30 Aug 2016 00:26:22 +0200 (CEST) (envelope-from jan.vrany@fit.cvut.cz) Message-ID: <1472509579.13311.23.camel@fit.cvut.cz> Subject: Debugging jitted code From: Jan Vrany To: "gdb@sourceware.org" Date: Mon, 29 Aug 2016 22:26:00 -0000 Content-Type: text/plain; charset="UTF-8" Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-FIT-MailScanner-ID: u7TMQMNF060160 X-FIT-MailScanner: Found to be clean X-FIT-MailScanner-SpamCheck: not spam, SpamAssassin (not cached, score=-1.526, required 7, autolearn=not spam, RP_MATCHES_RCVD -1.53) X-FIT-MailScanner-From: jan.vrany@fit.cvut.cz X-FIT-MailScanner-Watermark: 1473114385.44981@ZUvQmBqcIjecxtcFGktTLA X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg00058.txt.bz2 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