Executable file loading from weaver.elf

Sven Fülster mx at ...19...
Wed Jul 15 16:33:07 CEST 2009


Hi all,

I'm working on debugging some code, and going along with that, the qemu 
remote debugging turned out to be really nasty concerning an 
elfweaver-merged image.

I have a small elf image (built with elfweaver due to the OKL stuff), 
and this elf image contains a dde driver I've written.

Originally, my driver code was linked to a standard base address like 
any other executable built with the genode buildsystem.

--
kamikaze at ...22...:~/okl4/okl4_2.1.1-fix.7/genode-okl4-x86/bin$ 
readelf -S test-dde_linux26_net
There are 30 section headers, starting at offset 0x46b030:

Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg 
Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      
0   0  0
  [ 1] .text             PROGBITS        02000000 001000 06c1cc 00  AX  
0   0 128
  [ 2] .altinstr_replace PROGBITS        0206c1cc 06d1cc 00011d 00  AX  
0   0  1
  [ 3] .sched.text       PROGBITS        0206c2f0 06d2f0 000f26 00  AX  
0   0 16
  [ 4] .kprobes.text     PROGBITS        0206d216 06e216 000058 00  AX  
0   0  1
  [ 5] .spinlock.text    PROGBITS        0206d26e 06e26e 0001e7 00  AX  
0   0  1
  [ 6] .fixup            PROGBITS        0206d455 06e455 00002a 00  AX  
0   0  1
  [ 7] __ex_table        PROGBITS        0206d47f 06e47f 000130 00   A  
0   0  1
  [ 8] .data             PROGBITS        0206e000 06f000 009cc8 00  WA  
0   0 128
  [ 9] .got              PROGBITS        02077cc8 078cc8 000088 04  WA  
0   0  4
  [10] .got.plt          PROGBITS        02077d50 078d50 00000c 04  WA  
0   0  4
  [11] .init.setup       PROGBITS        02077d5c 078d5c 000030 00  WA  
0   0  4
  [12] .eh_frame         PROGBITS        02077d8c 078d8c 006c2c 00   A  
0   0  4
  [13] .gcc_except_table PROGBITS        0207e9b8 07f9b8 0012e0 00   A  
0   0  4
  [14] .altinstructions  PROGBITS        0207fc98 080c98 000473 00   A  
0   0  4
  [15] .smp_locks        PROGBITS        0208010c 08110c 0004ec 00   A  
0   0  4
  [16] __param           PROGBITS        020805f8 0815f8 000208 00   A  
0   0  4
  [17] .bss              NOBITS          02080800 081800 01e4e0 00  WA  
0   0 128
  [18] .debug_abbrev     PROGBITS        00000000 081800 0236a2 00      
0   0  1
  [19] .debug_info       PROGBITS        00000000 0a4ea2 2be0b6 00      
0   0  1
  [20] .debug_line       PROGBITS        00000000 362f58 03d9ac 00      
0   0  1
  [21] .debug_frame      PROGBITS        00000000 3a0904 01ff78 00      
0   0  4
  [22] .debug_loc        PROGBITS        00000000 3c087c 06426e 00      
0   0  1
  [23] .debug_pubnames   PROGBITS        00000000 424aea 015b4b 00      
0   0  1
  [24] .debug_aranges    PROGBITS        00000000 43a638 003858 00      
0   0  8
  [25] .debug_str        PROGBITS        00000000 43de90 029bf7 01  MS  
0   0  1
  [26] .debug_ranges     PROGBITS        00000000 467a88 003460 00      
0   0  8
  [27] .shstrtab         STRTAB          00000000 46aee8 000147 00      
0   0  1
  [28] .symtab           SYMTAB          00000000 46b4e0 011760 10     
29 1788  4
  [29] .strtab           STRTAB          00000000 47cc40 01b474 00      
0   0  1
--

Upon merging all the binaries with elfweaver, only the base address of 
'core' remained almost as it was linked originally. My driver instead 
was re-linked, so that its sections didn't overlap with any other.

--
Section Headers:
  [Nr] Name              Type            Addr     Off    Size   ES Flg 
Lk Inf Al
  [ 0]                   NULL            00000000 000000 000000 00      
0   0  0
 
  [10] core.text         PROGBITS        02000000 04b000 033590 00  AX  
0   0 32
  [11] core.data         PROGBITS        02034000 07f000 000ca4 00  WA  
0   0 32
  [12] core.got          PROGBITS        02034ca4 07fca4 000088 04  WA  
0   0  4
  [13] core.got.plt      PROGBITS        02034d2c 07fd2c 00000c 04  WA  
0   0  4
  [14] core.eh_frame     PROGBITS        02034d38 07fd38 007c88 00   A  
0   0  4
  [15] core.gcc_except_t PROGBITS        0203c9c0 0879c0 001858 00   A  
0   0  4
  [16] core.bss          NOBITS          0203e220 089218 01a570 00  WA  
0   0 32
 
  [21] test-dde_linux26_ PROGBITS        00c00000 2ff000 4980b4 00  WA  
0   0  1
  [22] bootinfo          PROGBITS        04004000 798000 001000 00  WA  
0   0  1
  [23] .shstrtab         STRTAB          00000000 799000 000116 00      
0   0  1
--

When I now start to remote-debug my stuff...

--
add-symbol-file 
/home/kamikaze/okl4/okl4_2.1.1-fix.7/genode-okl4-x86/bin/test-dde_linux26_net 
0x00c00000
--

...and set a breakpoint in dde_thread_main...

--
(gdb) b dde_thread_main
Breakpoint 2 at 0xc0183e: file 
/home/kamikaze/genode/sandbox/src/test/dde_linux26_net/main.cc, line 156.
(gdb) c
--

...this breakpoint is never triggered, although the thread obviously 
passes it.

So I wonder what init does when it starts up my code. Does my program's 
virtual address space look like the elfweaver-merged stuff?

Or does it look like the original (how would that work)?

Or does init even choose another base address? How would I then 
introduce the symbol-file to gdb?

Thanx in advance

Sven
--
Sven Fülster





More information about the users mailing list