This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

A little help with JIT support


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                                  . 		 	   		  

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]