This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
A little help with JIT support
- From: Rouslan Korneychuk <rouslank at msn dot com>
- To: "gdb at sourceware dot org" <gdb at sourceware dot org>
- Date: Tue, 30 Apr 2013 19:05:01 -0400
- Subject: 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 .