Frage:
Es kann kein spezieller PIC32-Linkerabschnitt in der Ausgabedatei angezeigt werden
tcrosley
2011-10-28 04:42:39 UTC
view on stackexchange narkive permalink

Ich definiere einen speziellen Abschnitt für einige Daten, die am Anfang meines PIC32-Binärbilds angezeigt werden sollen, wie im Abschnitt ABSCHNITTE meiner Datei elf32pic32mx.ld beschrieben: 

  .headerdata ORIGIN (kseg0_program_mem): {* (. headerdata)} >kseg0_program_mem

und dann initialisiere ich in meinem Code eine Struktur wie folgt: 

  const MODULEINFO SER_05_ModuleInfo __attribute __ ((Abschnitt (".headerdata"))) = {sizeof (MODULEINFO), // UINT16 HeaderSize MODULE_TYPE, // UNIT16 ModuleType // usw. usw.};

Wenn ich das Programm kompiliere und verknüpfe, wird die Struktur in der Zuordnungsdatei angezeigt: 

  .headerdata 0x9d000000 0x48 * (. Headerdata) .headerdata 0x9d000000 0x48 DriverHeader.o 0x9d000000 SER_05_ModuleInfo

, aber die tatsächlichen Daten werden nicht in der Hex-Ausgabedatei angezeigt.

Wenn ich das Attribut weglasse ((Abschnitt (".headerdata")) )) in t Die Struktur, die Struktur wird in den .rodata der Map-Datei angezeigt, und die Daten werden in meiner Hex-Ausgabedatei angezeigt.

Wenn Sie spezielle Abschnitte definieren, gibt es etwas muss das sonst noch getan werden, damit sie neben der Zeile> kseg0_program_mem tatsächlich eine Ausgabe generieren?

Einer antworten:
Austin Phillips
2011-10-30 16:36:30 UTC
view on stackexchange narkive permalink

In Anbetracht des dargestellten Codes zeigt ein Objektspeicherauszug der Header Folgendes an: 

  pic32-objdump -x main.o9 .rodata 00000004 00000000 00000000 00000360 2 ** 2 INHALT, ALLOC, LOAD, READONLY, CODE10 .headerdata 00000004 00000000 00000000 00000364 2 ** 2 INHALT, ALLOC, LOAD, DATA

Dies zeigt, dass der Abschnitt, in dem Header-Daten platziert werden, dies nicht tut haben die Attribute READONLY und CODE, was wiederum dazu führt, dass der Linker die Daten aus diesem Abschnitt anders verarbeitet. In meinen begrenzten Tests scheint es, dass Inhalte in .headerdata ​​code> wie andere Daten behandelt werden, was bedeutet, dass sie in einen speziellen Abschnitt mit dem Namen .dinit gestellt und von Flash nach geladen werden RAM beim Programmstart. Sie erwähnen, dass die Daten aus dem Abschnitt .headerdata ​​code> nicht in Ihrer Hex-Datei enthalten sind. Ich vermute, Sie finden sie im Abschnitt .dinit .

Wenn Sie versuchen, Funktionen zu erhalten, die .rodata ​​code> ähneln, aber Ihren eigenen Abschnittsnamen haben, müssen Sie Ihren Abschnitt .headerdata ​​code> mit einem zusätzlichen markieren r -Attribut wie folgt: 

  static const MODULEINFO SER_05_ModuleInfo __attribute __ ((Abschnitt (".headerdata, r"))) =

resultierend in einem Objekt-Header-Dump wie folgt: 

  9 .rodata 00000004 00000000 00000000 00000360 2 ** 2 INHALT, ALLOC, LOAD, READONLY, CODE 10 .headerdata 00000004 00000000 00000000 00000364 2 ** 2 INHALT , ALLOC, LOAD, READONLY, CODE

Dies wird dann ähnlich wie .rodata ​​code> im Linker behandelt, solange Sie Ihr spezielles Linker-Skript-Snippet als hinzugefügt haben aufgeführt.

Ich gehe davon aus, dass Sie versuchen, Ihren Header zum ersten Datensatz zu machen, der im Programmraum vorhanden ist. Obwohl die von Ihnen aufgelisteten Linker-Skript-Ergänzungen anscheinend funktionieren, ziehe ich es normalerweise vor, nur die zusätzlichen Abschnitte in Übereinstimmung mit den vorhandenen Abschnitten in der bevorzugten Reihenfolge hinzuzufügen. Anstelle eines separaten Abschnitts vom Typ .headerdata ORIGIN (kseg0_program_mem) können Sie den Abschnitt .text bearbeiten, um Folgendes zu erhalten: 

  .text: {* (. headerdata) * (. stub .gnu.linkonce.t. *) KEEP (* (. text. * persönlichkeit *)) * (. mips16.fn. *) * (. mips16. call. *) * (. gnu.warning)} >kseg0_program_mem

Die Verwendung von pic32-objdump -d main.elf zeigt eine vollständige Demontage der endgültigen Binärdatei in Hier sollten Ihre Header-Daten an der richtigen Adresse angezeigt werden.

Möglicherweise möchten Sie überprüfen, ob das Platzieren Ihres Headers am Anfang des Programmbereichs den Betrieb anderer Teile des Systems, z. B. die Ausnahmebehandlung, nicht beeinträchtigt.

Ich habe eine Kopie von pic30.c gcc-Compilercode gefunden, der irgendwo im Web herumschwirrt, und die akzeptierten Abschnittsattributflags scheinen zu sein:

b - BSS

x - Ausführbarer Code

r - Nur-Lese-Daten

d - Beschreibbare Daten

Vielen Dank, ich werde es heute Montagmorgen versuchen, wenn ich wieder zu meinem Job vor Ort komme, wo ich mich mit diesem Problem befasse. Die Attributflags waren mir nicht bekannt. Ich glaube nicht, dass sie im PIC32-Linker-Handbuch dokumentiert sind.
Der Abschnitt (".headerdata, r")) hat perfekt funktioniert. Vielen Dank.
Ich bin froh, dass es funktioniert hat. Ich bin überrascht über das Verhalten des Linkers und würde normalerweise erwarten, dass die Linker-Skripte die Abschnittszuordnung und den Code vom Typ crt0.S für das Laden der Daten übernehmen und den angegebenen Abschnitt nicht ignorieren. Darüber hinaus muss der Compiler möglicherweise auch den Abschnittstyp kennen, damit er die richtigen Anweisungen für die Adressierung auswählen kann. dh für Programm- / Datenraumzugriffe.


ⓘ
Diese Fragen und Antworten wurden automatisch aus der englischen Sprache übersetzt.Der ursprüngliche Inhalt ist auf stackexchange verfügbar. Wir danken ihm für die cc by-sa 3.0-Lizenz, unter der er vertrieben wird.
Loading...