A little help with JIT support

[Rouslan Korneychuk <rouslank@msn.com>]

I wanted to use GDB's JIT support feature in a JIT compiler I'm working on. This requires creating an object file, so I read the ELF and DWARF 4 specifications, and implemented the JIT data structures from the GDB manual. It all seems to be working except for one thing. The addresses used in the object file are supposed to be position independent "virtual" addresses, meaning they don't represent the final positions in memory. So my first function is at "address" 0, but GDB is treating these as absolute addresses. For example: if I try to use the "disassemble" command on my function, it tries to read from address 0 (which of course causes an error).

Are the addresses in an in-memory object file supposed to be absolute addresses? I figure I'm just missing something. Although using absolute addresses would work either way, I would prefer to know the proper way, so I would know how to create executable and dynamic library files. I looked at the information that GCC generates for object files, but it generates too much information for me to guess what mine is missing.


I'm using GDB 7.3.1

Here is an example of what I get when I run "readelf -hS" on my object file:

ELF Header:
  Magic:   7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 
  Class:                             ELF64
  Data:                              2's complement, little endian
  Version:                           1 (current)
  OS/ABI:                            UNIX - System V
  ABI Version:                       0
  Type:                              REL (Relocatable file)
  Machine:                           Advanced Micro Devices X86-64
  Version:                           0x1
  Entry point address:               0x0
  Start of program headers:          0 (bytes into file)
  Start of section headers:          4464 (bytes into file)
  Flags:                             0x0
  Size of this header:               64 (bytes)
  Size of program headers:           0 (bytes)
  Number of program headers:         0
  Size of section headers:           64 (bytes)
  Number of section headers:         8
  Section header string table index: 7

Section Headers:
  [Nr] Name              Type             Address           Offset
       Size              EntSize          Flags  Link  Info  Align
  [ 0]                   NULL             0000000000000000  00000000
       0000000000000000  0000000000000000           0     0     0
  [ 1] .text             PROGBITS         0000000000000000  00000050
       0000000000000fe0  0000000000000000  AX       0     0     16
  [ 2] .symtab           SYMTAB           0000000000000000  00001030
       0000000000000060  0000000000000018           3     4     0
  [ 3] .strtab           STRTAB           0000000000000000  00001090
       0000000000000018  0000000000000000           0     0     0
  [ 4] .debug_info       PROGBITS         0000000000000000  000010a8
       0000000000000054  0000000000000000           0     0     0
  [ 5] .debug_abbrev     PROGBITS         0000000000000000  000010fc
       000000000000001b  0000000000000000           0     0     0
  [ 6] .debug_str        PROGBITS         0000000000000000  00001117
       0000000000000011  0000000000000000           0     0     0
  [ 7] .shstrtab         STRTAB           0000000000000000  00001128
       0000000000000046  0000000000000000           0     0     0
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings), l (large)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)


And if I run "objdump -W"

file format elf64-x86-64

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x48 (32-bit)
   Version:       4
   Abbrev Offset: 0
   Pointer Size:  8
 <0><17>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <18>   DW_AT_use_UTF8    : 1    
 <1><18>: Abbrev Number: 2 (DW_TAG_subprogram)
    <19>   DW_AT_name        : (indirect string, offset: 0x0): $module$    
    <21>   DW_AT_high_pc     : 2051    
    <23>   DW_AT_low_pc      : 0x0    
 <1><2b>: Abbrev Number: 2 (DW_TAG_subprogram)
    <2c>   DW_AT_name        : (indirect string, offset: 0x9): gentest    
    <34>   DW_AT_high_pc     : 1650    
    <36>   DW_AT_low_pc      : 0x810    
 <1><3e>: Abbrev Number: 3 (DW_TAG_subprogram)
    <3f>   DW_AT_high_pc     : 287    
    <41>   DW_AT_low_pc      : 0xe90    
 <1><49>: Abbrev Number: 3 (DW_TAG_subprogram)
    <4a>   DW_AT_high_pc     : 48    
    <4b>   DW_AT_low_pc      : 0xfb0    

Contents of the .debug_abbrev section:

  Number TAG
   1      DW_TAG_compile_unit    [has children]
    DW_AT_use_UTF8     DW_FORM_flag_present
   2      DW_TAG_subprogram    [no children]
    DW_AT_name         DW_FORM_strp
    DW_AT_high_pc      DW_FORM_udata
    DW_AT_low_pc       DW_FORM_addr
   3      DW_TAG_subprogram    [no children]
    DW_AT_high_pc      DW_FORM_udata
    DW_AT_low_pc       DW_FORM_addr

Contents of the .debug_str section:

  0x00000000 246d6f64 756c6524 0067656e 74657374 $module$.gentest
  0x00000010 00                                  . 		 	   		  
From gdb-return-42073-listarch-gdb=sources.redhat.com@sourceware.org Wed May 01 00:51:43 2013
Return-Path: <gdb-return-42073-listarch-gdb=sources.redhat.com@sourceware.org>
Delivered-To: listarch-gdb@sources.redhat.com
Received: (qmail 23367 invoked by alias); 1 May 2013 00:51:43 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Delivered-To: mailing list gdb@sourceware.org
Received: (qmail 23192 invoked by uid 89); 1 May 2013 00:51:42 -0000
X-Spam-SWARE-Status: No, score=-5.1 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.1
Received: from mail-ve0-f182.google.com (HELO mail-ve0-f182.google.com) (209.85.128.182)    by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 01 May 2013 00:51:41 +0000
Received: by mail-ve0-f182.google.com with SMTP id da11so928118veb.27        for <gdb@sourceware.org>; Tue, 30 Apr 2013 17:51:40 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;        d=google.com; s 120113;        h=mime-version:x-received:in-reply-to:references:date:message-id         :subject:from:to:cc:content-type:x-gm-message-state;        bhßGgOnj7w5+2CPT9wLRaNUrybIr9zT+n5BSdu7xzE/E=;        b¿wDv479rzeU6sKrf+3kqhSn8qPfbQYcG+vPGKJSKF639utS4R34pAYq5DjEVAgD4u         gfuWLE4O10aCTogdS5eIIzR4UIWMsoIorzOeDJTQ/1LL9VhrvyOps5Jjsjno3HNc9AdJ         KTt1URJvHA5/FwxGkbN7aIY4jn7r0H5voAE/+8kWcXu7CqCt7a0egvIGKKszhzpnmNN4         /6w3E95neGV6n4mKtzT9eUJL/c0PleVw+6+WqF57ck3rACNxTJ04ZuU9XgUPKyvTrCDS         3Igmo6KQKkxolW5gLTQMuNMb2NePCGUoQDZisLn2t0cAn0saly+ttZn/ssSMjJUsxMI3         gWQw=MIME-Version: 1.0
X-Received: by 10.52.24.113 with SMTP id t17mr219956vdf.30.1367369499938; Tue, 30 Apr 2013 17:51:39 -0700 (PDT)
Received: by 10.220.173.7 with HTTP; Tue, 30 Apr 2013 17:51:39 -0700 (PDT)
In-Reply-To: <1367308142.25105.25.camel@Renee-desktop.suse>
References: <1367308142.25105.25.camel@Renee-desktop.suse>
Date: Wed, 01 May 2013 00:51:00 -0000
Message-ID: <CADPb22Qoz7-fDCXq^iw_OA8VQDOOji_AETrxBy+d_AR0jDdg@mail.gmail.com>
Subject: Re: About adding new script language
From: Doug Evans <dje@google.com>
To: Nala Ginrut <mulei@gnu.org>
Cc: "gdb@sourceware.org" <gdb@sourceware.org>
Content-Type: text/plain; charset=ISO-8859-1
X-Gm-Message-State: ALoCoQlbup4eI7RdNOOGEZOhEFUASgnN3FhluAbeg1mUmk9JJqz+vPuIoEpGwtGY3YanR4ifFzM5y6ALCZC1xXtFVVYzsOMZ8Pje2Eslf/MLaeL9oEtqyPCvRR72EgDTdwzUwfUndaOnCcjE8e9xs2rs3+V1JTdY+1nLiBKEJss6IfoaepEwNOFQZQrYsyZM2qdhhv1lF4I3
X-SW-Source: 2013-05/txt/msg00000.txt.bz2
Content-length: 2131

On Tue, Apr 30, 2013 at 12:49 AM, Nala Ginrut <mulei@gnu.org> wrote:
> Hi GDB folks!
> I'm new comer here, and I'm trying to make guile the extension language.
> Anyway, folks could use python as well, before guile has reliable python
> front-end.
> I've read the python part, here're some ideas, correct me if I'm wrong
> please. ;-)
>
> 1. Is it necessary to use language_defn to define the extension
> language?
> My understanding is language_defn defines a new language support for
> debugging the defined language, not to define a new extension language
> for other debugging purpose. Or not?
> For example, go-lang.c is the support for debugging go, not add go as
> the debug script language, just like python. But it confused me that
> python has used language_defn.

Hi.
Your interpretation of language_defn is correct.
The Python extension support in GDB uses language_defn only to implement
various API calls.  E.g. when printing a value one might want to know the
(programming) language in which to print it.

> 2. There should be interfaces to add the script language, but I didn't
> find it, anyone point me out? I don't think I have to write new
> lexer/parser for that, just need a way to get the expr and call guile's
> read function. Thanks!

There aren't any interfaces, they need to be added.
One of the hardest parts of adding Guile support to GDB (as an
extension language)
will be providing reasonable interfaces.

> 3. My aim is not only add guile as an extension in gdb's REPL, but a
> more powerful language for the automatic debugging. For that purpose,
> the hard/heavy work is not to add guile into gdb, but a framework
> project implemented by guile based on the support of guile-gdb.
> Is this idea too unrealistic?

It's not unrealistic.  It's easier to add a second one now that the
first is there.
However, as I said, adding clean interfaces will be important.
We want the end result to be maintainable, and supporting multiple
extension languages is going to complicate things.
[It will be easier in the sense that we're not interested in supporting
and arbitrary number of extension languages.]