shared Objekt auf Cortex-M4 seltsame Symbole in Dynsym Abschnitt

Question

Ich schreibe tatsächlich einen gemeinsamen Objektlader, der mit dem gcc erstellt shared-objects (ELF) auf einem Cortex-m4-Controller geladen wird. Das Laden, das Lösen von Abhängigkeiten und das Verschieben von Dateien usw. funktioniert einwandfrei. Aber das gemeinsame Objekt hat einige seltsame Symbole in der .dynsym-Sektion, mit denen ich nicht umgehen kann.

readelf --dyn-sym libfoo.so

Num: Wert Size Typ  Bind Vis  Ndx Name                              
0: 00000000  0 NOTYPE LOCAL DEFAULT UND                                
1: 000005c8  0 SECTION LOCAL DEFAULT 8                                
2: 00000874  0 SECTION LOCAL DEFAULT 16                                
3: 00000000  0 NOTYPE GLOBAL DEFAULT UND printf                              
4: 0000082d 32 FUNC GLOBAL DEFAULT 12 foo3                              
5: 0000087c  0 NOTYPE GLOBAL DEFAULT 18 __bss_start__                            
6: 00000000  0 NOTYPE GLOBAL DEFAULT UND __libc_init_array                           
7: 00000728  0 NOTYPE GLOBAL DEFAULT 12 _mainCRTStartup                            
8: 000005c8  0 FUNC GLOBAL DEFAULT 8 _init                              
9: 00000000  0 NOTYPE GLOBAL DEFAULT UND __libc_fini_array                           
10: 00000000  0 NOTYPE WEAK DEFAULT UND __deregister_frame_info                          
11: 00000000  0 NOTYPE WEAK DEFAULT UND _ITM_registerTMCloneTable                         
12: 00000898  0 NOTYPE GLOBAL DEFAULT 18 __bss_end__                             
13: 00000728  0 NOTYPE GLOBAL DEFAULT 12 _start                              
14: 00000000  0 NOTYPE WEAK DEFAULT UND software_init_hook                           
15: 00000000  0 NOTYPE WEAK DEFAULT UND _ITM_deregisterTMCloneTab                         
16: 00000000  0 NOTYPE GLOBAL DEFAULT UND memset                              
17: 00000000  0 NOTYPE GLOBAL DEFAULT UND main                              
18: 00000000  0 NOTYPE WEAK DEFAULT UND hardware_init_hook                           
19: 000005e0  0 FUNC GLOBAL DEFAULT 9 _fini                              
20: 00000000  0 NOTYPE GLOBAL DEFAULT UND atexit                              
21: 00000000  0 NOTYPE WEAK DEFAULT UND __stack                              
22: 00000000  0 NOTYPE GLOBAL DEFAULT UND exit                              
23: 00000000  0 NOTYPE WEAK DEFAULT UND _Jv_RegisterClasses                           
24: 00000000  0 NOTYPE WEAK DEFAULT UND __register_frame_info 

Warum das gemeinsame Objekt einen Verweis auf eine Haupt-Funktion und auf die __libc_init_array Funktion benötigen? Vor allem das Symbol für __libc_init_array macht für mich keinen Sinn ... Diese Funktion initialisiert normalerweise __pretinit_array, _init und __init_array, aber dieser Job sollte von meinem Loader ausgeführt werden, nicht vom Objekt selbst, oder ich liege falsch?

Gibt es irgendwo eine Schritt-für-Schritt-Dokumentation, wie man ein geladenes Shared-Objekt mit all seinen Abhängigkeiten initialisiert?

Dies ist die Art und Weise, wie ich mein Shared-Objekt bauen:

gcc -std=gnu99 -W -Wall -Wstrict-prototypes -Wmissing-prototypes -ffunction-sections -fdata-sections -mfloat-abi=soft -mcpu=cortex-m4 -mthumb -mlong-calls -Os -g -c -fPIC -o foo.o foo.c 

gcc -shared -fPIC -Wl,-soname,libfoo.so -T./shared.ld -o libfoo.so foo.o 

Es ist nur noch eine Frage: Ohne die -MLONG-Anrufe Option, mein gcc ungültigen Befehlscode in dem PLT-Abschnitt erzeugt .. Was mache ich falsch?

EDIT: Mein foo.c ist verry einfach:

#include <stdio.h> 
#include <string.h> 

void foo3 (void) 
{ 
    printf("Hello from shared-object"); 
} 

Das ist mein shared.ld:

OUTPUT_FORMAT("elf32-littlearm", "elf32-bigarm", "elf32-littlearm") 

OUTPUT_ARCH(arm) 

SECTIONS 
{ 
    .interp   : { *(.interp) } 
    .note.ABI-tag : { *(.note.ABI-tag) } 

    .gnu.version : { *(.gnu.version) } 
    .gnu.version_d : { *(.gnu.version_d) } 
    .gnu.version_r : { *(.gnu.version_r) } 

    .dynamic  : { *(.dynamic) } 

    .hash   : { *(.hash) } 
    .dynsym   : { *(.dynsym) } 
    .dynstr   : { *(.dynstr) } 

    .rel.dyn  : { *(.rel.dyn) } 
    .rela.dyn  : { *(.rela.dyn) } 
    .rel.plt  : { *(.rel.plt) } 
    .rela.plt  : { *(.rela.plt) } 

    .plt   : { *(.plt) } 
    .got   : { *(.got.plt) *(.got) } 

    .init ALIGN(32/8) : 
    { 
     KEEP (*(.init)) 
    } 

    .fini ALIGN(32/8) : 
    { 
     KEEP (*(.fini)) 
    } 

    .preinit_array ALIGN(32/8) : 
    { 
     PROVIDE(__preinit_array_start = .); 
     KEEP (*(.preinit_array)) 
     PROVIDE(__preinit_array_end = .); 
    } 

    .init_array ALIGN(32/8) : 
    { 
     PROVIDE(__init_array_start = .); 
     KEEP (*(.init_array*)) 
     PROVIDE(__init_array_end = .); 
    } 

    .fini_array ALIGN(32/8) : 
    { 
     PROVIDE(__fini_array_start = .); 
     KEEP (*(.fini_array*)) 
     PROVIDE(__fini_array_end = .); 
    } 

    .text ALIGN(32/8) : 
    { 
     *(.text .text.*) 
    } 

    .rodata ALIGN(32/8) : 
    { 
     *(.rodata .rodata.*) 
    } 

    .data ALIGN(32/8) : 
    { 
     *(.data .data.*) 
    } 

    .bss ALIGN(32/8) : 
    { 
     PROVIDE(__bss_start__ = .); 

     *(.bss .bss.*) 
     *(COMMON) 

     PROVIDE(__bss_end__ = .); 
    } 
} 

HINWEIS: Der Verweis auf printf gesetzt zum printf meines Hauptprogramms bei linktime - nur zum Testen.

danke für deine hilfe :-)

Answer 1

ich löste das erste problem! -nostartfiles war mein Freund :-)

ohne das ganze crtxxx Zeug ist die Bibliothek jetzt sauber!

Das Problem mit dem ungültigen Opcode existiert noch, aber ich benutze GCC in Version 4.7.4, so dass dieser "Bug" vielleicht heute behoben wird.