2017-11-29 16 views
2

HINTERGRUND verknüpftgcc Linker - OBJ-Dump hat Quelle-Baugruppe gemischt, aber nicht, wenn sie in .elf

Ich habe ein Projekt unter Verwendung von C-Code und C++ Code. Die Verknüpfung ist kein Problem: Die C-Funktionen werden korrekt vom C++ - Code aufgerufen.

Alle meine .cpp Dateien werden mit -g3 kompiliert, sondern nur main.c und pyexec.c sind -g3; Rest hat keine Debug-Informationen.

Der Verknüpfungsschritt besteht aus der Verknüpfung einiger .cpp Archive, .cpp Objekte und Archiv mit .c Objekte.

PROBLEM

Wenn ich ein objdump auf meinem .elf

objdump APP.elf -dSsxsgetr > elf.dump

ich die Quelle der .cpp Dateien sehen mit der Montage durchsetzt, aber nicht für die beiden .c Dateien mit -g3 zusammengestellt .

DOUBLE-CHECK

Ich bin absolut sicher, dass ich main.c und pyexec.c mit -g3 zusammengestellt. Als ich eine objdump -dSsxsgetrmain.obj machte, sehe ich die Quelle mit der Assembly zusätzlich Debug-Symbole wie .debug_line durchsetzt, die die gesamte Quelle meiner .c Datei enthält.

Meine Link-Befehl ist:

arm-none-eabi-ld.exe HW_Interface.obj HW_Module.obj HeapMngr.obj C_archive.a Cpp_archive.a -nostartfiles --no-warn-mismatch --gc-sections --stats --cref -Map=APP.map -T "APP.ld" -o "APP.elf"

FRAGE

Warum sind nicht die Debug-Zeilennummern aus den .c Objekte zusammengestellt mit -g3 in die .elf bekommen?

UPDATE 1

Ich denke, was die Symbole Strippen ist mein Linker-Skript-Anweisung mit der --gc-sections Option an den Linker kombiniert ist:

.dflash_code : 
    { 
    *ATI_micropython.dlb:*(.text.*) 
    *ATI_micropython.dlb:*(.debug*) 

    } >dflash 

Diese Aussage ist "richtig", aber was geschieht, (Ich denke) ist, dass, weil ich nicht explizit angeben, was auch immer Eingangsabschnitt enthält die Zeile-für-Zeile-Informationen und, weil --gc-sections sagt verwerfen alle "unbenutzten" Abschnitte, diese Information wird gelöscht.

Die eigentliche Frage ist also: Was ist der Eingabeabschnitt, den ich zu .dflash_code hinzufügen muss, die die gemischte Quellbaugruppe enthält? Der Abschnitt .debug_line ist bereits enthalten und enthält die gesamte Quelle für eine bestimmte Datei.

In gibt es einen Abschnitt namens Discarded input sections. In diesem Abschnitt sehe ich, dass nur für meine zwei .c Debug-Dateien gibt es eine Reihe von .debug_macro Aussagen. . . was macht keinen Sinn, weil alle solche Abschnitte erfasst haben sollte (es sei denn, ich missverstand ihren Zweck).

.debug_macro 0x00000000  0x3a ..\archive.dlb(main.doj) 
.debug_macro 0x00000000  0x35 ..\archive.dlb(main.doj) 
.debug_macro 0x00000000  0x3a ..\archive.dlb(main.doj) 
.debug_macro 0x00000000  0x52 ..\archive.dlb(main.doj) 
.debug_macro 0x00000000  0x19 ..\archive.dlb(main.doj) 
.debug_macro 0x00000000  0x189 ..\archive.dlb(main.doj) 
.debug_macro 0x00000000  0x10 ..\archive.dlb(main.doj) 
.debug_macro 0x00000000  0x22 ..\archive.dlb(main.doj) 
.debug_macro 0x00000000  0x91 ..\archive.dlb(main.doj) 
+0

Ist es möglich, dass, was auch immer die C-Objekt-Dateien in das Bibliotheksarchiv legt, das Entfernen von Symbolen ist? –

+0

@MichaelBurr nein, um die '.obj's zu überprüfen, entzippe ich das Archiv der Bibliothek, aber ich denke, ich weiß, was das Entfernen der Symbole ist; Siehe mein Update in Kürze. – Adrian

+0

@MichaelBurr aktualisiert – Adrian

Antwort

1

finden schließlich den Grund, aber ich verstehe immer noch nicht, warum dies geschieht:

In der Linker-Datei, wenn ich mit .debug in ihrem Namen wie .debug_macro in einem anderen Abschnitt alle Abschnitte platzieren :

.dflash_code : 
    { 
    *archive.dlb:*(.text.*) 
    *archive.dlb:*(.debug*)  
    } >dflash 

Dann in der ELF .map Datei werde ich diese Abschnitte in der .elf (kein duh) platziert bekommen einschließlich .debug_line, die in dem .obj s, die gesamte Quelle der entsprechenden .c enthält:

app.elf.map:

.debug_line 0x1001841d  0x87e ..\archive.dlb(main.doj) 
.debug_line 0x10026152  0x8fe ..\archive.dlb(pyexec.doj) 

Allerdings, wenn ich objdump -Sxg app.elf laufen, ich habe nicht die Quelle mit Montage vermischten :

Disassembly of section .dflash_code: 
10000000 <micropython_main>: 
10000000: b580  push {r7, lr} 
10000002: b084  sub sp, #16 
10000004: af00  add r7, sp, #0 
10000006: 6078  str r0, [r7, #4] 
10000008: 6039  str r1, [r7, #0] 
1000000a: 4b09  ldr r3, [pc, #36] ; (10000030 <micropython_main+0x30>) 
1000000c: f107 020c add.w r2, r7, #12 
10000010: 601a  str r2, [r3, #0] 
10000012: f001 ff6d bl 10001ef0 <mp_init> 
10000016: 4807  ldr r0, [pc, #28] ; (10000034 <micropython_main+0x34>) 
10000018: f006 f88e bl 10006138 <pyexec_frozen_module> 
1000001c: f001 ff94 bl 10001f48 <mp_deinit> 
10000020: f04f 0300 mov.w r3, #0 
10000024: 4618  mov r0, r3 
10000026: f107 0710 add.w r7, r7, #16 
1000002a: 46bd  mov sp, r7 
1000002c: bd80  pop {r7, pc} 
1000002e: bf00  nop 
10000030: 1fff34fc .word 0x1fff34fc 
10000034: 100313bc .word 0x100313bc 

wenn ich jedoch die Linker-Datei so ändern, dass die .debug* Abschnitte von archive.dlb sind nicht in .dflash_code platziert (und ich wiederhole dies die nur Änderung ich machen):

.dflash_code : 
    { 
    *archive.dlb:*(.text.*) 

    } >dflash 

Dann in der ELF .map Datei, habe ich noch die gleichen .debug_line Abschnitte sieht sie jedoch an einer anderen Stelle platziert werden wegen einiger anderer Aussagen später in der meine Linker Datei

app.elf.map:

.debug_line 0x00082a32  0x87e ..\archive.dlb(main.doj) 
.debug_line 0x000832b0  0x8fe ..\archive.dlb(pyexec.doj) 

und was am wichtigsten ist, laufen objdump -Sxg app.elf gibt die vermischte Quelle-Baugruppe

int micropython_main(char * uP_heap, unsigned int heap_size) 
{ 
10000000: b580  push {r7, lr} 
10000002: b084  sub sp, #16 
10000004: af00  add r7, sp, #0 
10000006: 6078  str r0, [r7, #4] 
10000008: 6039  str r1, [r7, #0] 
    int stack_dummy; 
    stack_top = (char*)&stack_dummy; 
1000000a: 4b09  ldr r3, [pc, #36] ; (10000030 <micropython_main+0x30>) 
1000000c: f107 020c add.w r2, r7, #12 
10000010: 601a  str r2, [r3, #0] 
    #if MICROPY_ENABLE_GC 
     gc_init(uP_heap, uP_heap + heap_size); 
    #endif 
    mp_init(); 
10000012: f001 ff6d bl 10001ef0 <mp_init> 

    pyexec_frozen_module("main.py"); 
10000016: 4807  ldr r0, [pc, #28] ; (10000034 <micropython_main+0x34>) 
10000018: f006 f88e bl 10006138 <pyexec_frozen_module> 

    mp_deinit(); 
1000001c: f001 ff94 bl 10001f48 <mp_deinit> 

    return 0; 
10000020: f04f 0300 mov.w r3, #0 
} 
10000024: 4618  mov r0, r3 
10000026: f107 0710 add.w r7, r7, #16 
1000002a: 46bd  mov sp, r7 
1000002c: bd80  pop {r7, pc} 
1000002e: bf00  nop 
10000030: 1fff34fc .word 0x1fff34fc 
10000034: 1001eaf4 .word 0x1001eaf4 

Also warum ist es ganz gleich, wo ich die Abschnitte setze .debug*? Ich denke nicht, dass es technisch ist. Der Teil meiner Linker-Datei, die die Platzierung der ZWERG Symbole wirkt sich wie folgt aussieht:

.debug_info  0 : { *(.debug_info .gnu.linkonce.wi.*) } 
    .debug_abbrev 0 : { *(.debug_abbrev) } 
    .debug_line  0 : { *(.debug_line) } 
    .debug_frame 0 : { *(.debug_frame) } 
    .debug_str  0 : { *(.debug_str) } 
    .debug_loc  0 : { *(.debug_loc) } 
    .debug_macinfo 0 : { *(.debug_macinfo) } 

ich die Bestellung irgendwie zählt zu erraten.

+1

Froh, dass Sie eine Lösung gefunden haben - Linker-Skripte sind für mich größtenteils Voodoo. –

Verwandte Themen