Forum: Compiler & IDEs bestimmte gnu-arm-as Version im Netz finden


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
Gibt es irgendwo ein Repositorium, wo man ältere gnu-arm-tools finden 
kann? Ich muß eine ältere Programmierumgebung (Windows) mit dem 
vergleichen, was ich davon jetzt nach Unix (macOS) portiert habe. Beim 
Vergleich der Kompilate (Assembler Listing) stelle ich fest, daß der 
generierte Code ab einer bestimmten Stelle auseinanderläuft.

Der ältere Assmbler ist:
GNU assembler (GNU Tools for ARM Embedded Processors) 2.24.0.20150304
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.

Der neuere:
GNU assembler (GNU Tools for Arm Embedded Processors 8-2018-q4-major) 2.31.51.20181213
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Alte Binutils selbst compilieren?

Muss es denn unbedingt die Windows-Version sein, oder ist nur die genaue 
Assemblerversion wichtig? Ansonsten würde ich das an deiner Stelle unter 
FreeBSD oder Linux machen.

: Bearbeitet durch Moderator
von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Alte Binutils selbst compilieren?
>

Wäre die letzte Möglichkeit. Vielleicht auch der Weg, den ich letztliich 
gehen muß.

> Muss es denn unbedingt die Windows-Version sein, oder ist nur die genaue
> Assemblerversion wichtig? Ansonsten würde ich das an deiner Stelle unter
> FreeBSD oder Linux machen.

Ich will ja von der Windows-Version runter. D.h., das ist die Referenz, 
die ich unangetastet lasse. Jetzt ziehe ich mit den Sourcen um und 
kompiliere gerade, um anschließend das generierte Binary mit dem Windows 
Binary zu vergleichen, bevor ich auf .elf umstelle.

Aber beim Vergleich stelle ich Abweichungen fest, die ich natürlich 
vermeiden will, einfach um erst mal formal sicherzustellen, daß ich in 
der Lage bin, ein exaktes Abbild des Zielsystems auch außerhalb der 
ursprünglichen Entwicklungsumgebung generieren zu können.

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Naja, die Binutils bauen auf heutigen Maschinen in ein paar Minuten. 
Setz den --prefix beim ./configure so, dass das Resultat dann außerhalb 
der normalen Verzeichnisse liegt, damit hast du dann Assembler und 
Linker auf exakt dem Stand, der seinerzeit auf Windows benutzt worden 
ist.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Naja, die Binutils bauen auf heutigen Maschinen in ein paar Minuten.
> Setz den --prefix beim ./configure so, dass das Resultat dann außerhalb
> der normalen Verzeichnisse liegt, damit hast du dann Assembler und
> Linker auf exakt dem Stand, der seinerzeit auf Windows benutzt worden
> ist.

Werde mal einen Versuch unternehmen...

von W.S. (Gast)


Bewertung
-1 lesenswert
nicht lesenswert
Christoph K. schrieb:
> um anschließend das generierte Binary mit dem Windows
> Binary zu vergleichen, bevor ich auf .elf umstelle.

Hä?
Also sowohl der GCC als auch der Keil erzeugen zu allererst ein ELF File 
(egal wie die konkrete Endung auch sein mag) und man muß daraus mit 
FromElf oder dem GCC-Pendant dazu das .bin oder .hex oder .s19 erzeugen.

So herum geht das.

W.S.

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Also sowohl der GCC als auch der Keil erzeugen zu allererst ein ELF File

Erstens hat er gar keinen C-Compiler, zweitens hast du im Prinzip Recht: 
der Linker wirft ein ELF-File raus.

Aber: Chris will einen existierenden, bislang unter Windows arbeitenden 
Flow, der am Ende ein Hexfile erzeugt hat, durch einen auf einem 
aktuellen Unix ersetzen mit aktuellen Tools, der es am Ende bei einem 
ELF-File belassen soll (das Hexfile braucht keiner). Er will aber dabei 
sicherstellen, dass bei der Transformation tatsächlich auch das gleiche 
Resultat entsteht wie dazumals unter der Windows-Toolchain.

von User (Gast)


Bewertung
1 lesenswert
nicht lesenswert
Du könntest hier schauen ob der da dabei ist:
https://launchpad.net/gcc-arm-embedded/+series

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
W.S. schrieb:
> Christoph K. schrieb:
>> um anschließend das generierte Binary mit dem Windows
>> Binary zu vergleichen, bevor ich auf .elf umstelle.
>
> Hä?
> Also sowohl der GCC als auch der Keil erzeugen zu allererst ein ELF File
> (egal wie die konkrete Endung auch sein mag) und man muß daraus mit
> FromElf oder dem GCC-Pendant dazu das .bin oder .hex oder .s19 erzeugen.
>
> So herum geht das.
>
> W.S.

Das ist zwar richtig, daß das erste Zwischenprodukt ein .elf file ist,
aber die Situation - und das kannst Du nicht wissen - ist die, daß der 
Build-Prozeß unter Windows bei dem System, das ich so vorgefunden habe, 
so ist, daß ein absolutes Binary erzeugt wird und diesem Binary per 
Script (Clisp), gewonnen aus der Symbol-Tabelle, noch ein weiterer 
binärer Block von Pseudo-Code (Threaded Code tokens) angehängt wird. Um 
diese Codes zu kennen, muß zuerst das Compilat erzeugt werden (kernel).

Ja, das klingt umständlich und blöd und getrickst, aber es ist halt so.

von Christoph K. (chriskuku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
User schrieb:
> Du könntest hier schauen ob der da dabei ist:
> https://launchpad.net/gcc-arm-embedded/+series

Das sieht auf den ersten Blick ganz gut aus. Habe mal eine Version aus 
2014 installiert, die aber noch nicht den gleichen Code erzeugt - wir 
reden hier von Assembler und nicht C. Da sollte man meinen Assembler, 
der Programmierer selbst codiert hat, sollte immer den gleichen 
Binärcode erzeugen.

Ich poste mal die Stelle, wo es das erste mal auseinanderläuft.
(siehe Screenshot aus einem Beyond-Compare Vergleich).

Vielleicht sieht jemand daran, was der Assembler hier "meint", gegenüber 
seinem 2.24-"Kollegen" anders machen zu müssen.

Vielleicht gibt es ja einen Schalter, der gewisse Optimierungen steuert?

von Christoph K. (chriskuku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe mich jetzt an die Version herangetastet:

GNU assembler (GNU Tools for ARM Embedded Processors) 2.24.0.20150604
Copyright 2013 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms 
of
the GNU General Public License version 3 or later.
This program has absolutely no warranty.
This assembler was configured for a target of `arm-none-eabi'.


Die erste Differenz zum Original ist weg. Aber weiter im File gibt es 
weitere Unterschiede.

Ich weiß nicht, ob ich überhaupt zu einer Übereinstimmung kommen kann.
Diesmal sind es branches, die anders assembliert werden.

von Bauform B. (bauformb)


Bewertung
0 lesenswert
nicht lesenswert
> Vielleicht sieht jemand daran, was der Assembler hier "meint",
> gegenüber seinem 2.24-"Kollegen" anders machen zu müssen.

Anscheinend passiert das hier: LDR R0, = ACRCONF kann als MOV R0, 
#ACRCONF übersetzt werden -- falls die Konstante klein genug ist. 
Ansonsten braucht man ein LDR mit der Konstanten im Pool. Leider 
unterscheiden sich die Assembler-Versionen an der Stelle nicht 
(zumindest offiziell):
https://sourceware.org/binutils/docs-2.24/as/ARM-Opcodes.html#ARM-Opcodes
https://sourceware.org/binutils/docs-2.31/as/ARM-Opcodes.html#ARM-Opcodes

Allerdings muss ein LDR auch dann erzeugt werden, wenn die CPU den 
MOV-Befehl nicht kennt. Der neuere Assembler unterscheidet sicher mehr 
Varianten, vielleicht kann man mit -march, -mcpu, -mtune, -mcompat? o.ä. 
etwas erreichen.

Noch eine Quelle für alte Quellen:
ftp://sourceware.org/pub/binutils/snapshots/

von Michael D. (nospam2000)


Bewertung
0 lesenswert
nicht lesenswert
für Debian Pakete kannst du über http://snapshot.debian.org/ auf alte 
Versionen des Repositories zurückgreifen. Geht zurück bis 2005.

von M.M.M (Gast)


Bewertung
0 lesenswert
nicht lesenswert
Christoph K. schrieb:
> Gibt es irgendwo ein Repositorium, wo man ältere gnu-arm-tools finden
> kann?

https://launchpad.net/gcc-arm-embedded/+series

von Christoph K. (chriskuku)


Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Habe jetzt die passende Version gefunden, die exakt den gleichen Code 
erzeugt.
Nur die Darstellung der Symbole am Ende des Listings (long in der 
Unix-Version vs. Word unter Windows). Wahrscheinlich liegt es an der 
Plattform.
Das Windows-Binary des toolchain-as ist eine 32-bit App, die neue 
Plattform ist 64bit. Aber praktisch habe ich Identität im Binary 
erzielt.

Danke allen für die Mithilfe.

Grüße und ein schönes Wochenende
Christoph

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph K. schrieb:
> Das Windows-Binary des toolchain-as ist eine 32-bit App, die neue
> Plattform ist 64bit.

Ja, die 64er zeigt die Zahlen länger an.

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
Noch ein Gedanke zum weiteren Vorgehen, jetzt, nachdem ich 1:1 
Übereinstimmung gewährleistet habe:

Die Erzeugung des Target-Binaries geschieht ja in der Weise, daß 
zunächst ein Kernel gebaut wird:
$(ARM_PATH)$(ARMGNU)-objcopy -O binary kernel.o  kernel.bin
und anschließend, mit Hilfe der Symboltabelle ein weiteres Kompilat aus 
High-Level FORTH Worten hinten angehängt wird auf eine geraden Adresse 
beginnend. Das erzeugte image.bin wird dann geflasht.

Wenn ich das nun mittels gdb und openOCD debuggen wollte (.elf), müßte 
ich den Prozeß derart ändern, daß ich einmal die Symboltabelle erstelle, 
das FORTH Kompilat baue und dieses binäre Paket in den ld-Schritt 
einbaue - weiß im Moment nicht, wie ein man ein raw-binary dazulinken 
kann. Könnte es höchstens wieder in die Source als Datenworte einbauen 
und in einem zweiten Schritt noch mal assemblieren.

Anderer Gedanke ist jetzt der:

Das raw-Binary komplett mit st-flash erase, st-flash write in das Target 
zu laden und dem openOCD/gdb zu sagen, er solle nicht flashen.
Dann könnte ich das .elf-Image zum Debuggen benutzen, denn das 
entspricht ja dem geladenen Binärcode.

Meinungen dazu? Wie muß ich openOCD/gdb konfigurieren, daß es nicht 
flasht?

: Bearbeitet durch User
Beitrag #6444954 wurde von einem Moderator gelöscht.
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
Christoph K. schrieb:
> Meinungen dazu? Wie muß ich openOCD/gdb konfigurieren, daß es nicht
> flasht?

OpenOCD flasht erstmal nichts von sich aus. Es ist nur ein GDB-Server 
(ok, und ein Telnet-Server), der macht, was du ihm sagst. Solange du ihm 
also nicht sagst, er solle was flashen, tut er das nicht.

OpenOCD kann direkt (also über das telnet-Interface oder auch gleich 
über die Kommandozeile) flashen, da brauchst du nicht unbedingt noch die 
ST-Software, oder aber es kann natürlich auch vom GDB aus flashen.

>
> $(ARM_PATH)$(ARMGNU)-objcopy -O binary kernel.o  kernel.bin
> 

Aus einem (verschieblichen) .o ein .bin zu extrahieren, erscheint mir, 
nun, sehr seltsam.

> und anschließend, mit Hilfe der Symboltabelle ein weiteres Kompilat aus
> High-Level FORTH Worten hinten angehängt wird auf eine geraden Adresse
> beginnend. Das erzeugte image.bin wird dann geflasht.

Wie erfolgt die Einbindung in den Kernel? Vermutlich wird doch da die 
Adresse einer Liste irgendwo eingetragen, ab der er die FORTH-Worte dann 
sucht, oder?

Ich würde die FORTH-Worte stattdessen wohl in einen "binary blob" 
umwandeln, deren Anfang ein Symbol geben, und das alles zusammen linken.

> weiß im Moment nicht, wie ein man ein raw-binary dazulinken
> kann.

Wenn du mit [arm-none-eabi-]objcopy aus einem Binärklumpen eine 
Objektdatei kopierst, generiert er automatisch ein paar Symbole, die aus 
dem Dateinamen abgeleitet werden:
$ # Erzeugen von Dummy-Daten
$ dd if=/dev/urandom of=test.bin bs=20 count=1
1+0 records in
1+0 records out
20 bytes transferred in 0.000121 secs (164989 bytes/sec)
$ # Umwandeln in ELF-Objekt
$ objcopy -I binary -O elf64-x86-64-freebsd test.bin test.o
$ nm test.o
0000000000000014 D _binary_test_bin_end
0000000000000014 A _binary_test_bin_size
0000000000000000 D _binary_test_bin_start

von Christoph K. (chriskuku)


Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Wie erfolgt die Einbindung in den Kernel? Vermutlich wird doch da die
> Adresse einer Liste irgendwo eingetragen, ab der er die FORTH-Worte dann
> sucht, oder?

Der kernel endet auf

@--------------------------------------------------------------------
                .global primitives_cutoff, endOfDictionary
primitives_cutoff:
endOfDictionary:

Ab hier werden 16-Bit FORTH tokens aneinandergereiht. Ein FORTH Programm 
ist eine Aneinanderreihung von Pseudocode-Worten. Dieser Pseudocode 
besteht aus Adressen aus dem Kernel-Binary. Der "Klumpen" wird da 
einfach angeklebt, word-aligned.


Die Einbindung in den Kernel erfolgt durch ein Common Lisp Programm, das 
das FORTH-System kompiliert, und das Kompilat an den kernel.bin anklebt.
Dazu muß der FORTH-Compiler die Symbole des Kernels kennen.

Werde mir Deine Vorschläge mal zu Gemüte führen.

Grüße
Christoph

: Bearbeitet durch User

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.