Moin Gemeinde,
bin gerade wieder einmal an einem größeren Arm-Assembler Projekt und
habe eine etwas nervende Eigentümlichkeit beim ›arm-none-eabi-as‹
festgestellt.
Das Ding liest und verarbeitet zwar utf-8 Quelldateien problemlos,
generiert man sich allerdings ein Listing dann wird's unattraktiv:
1
GNU assembler version 2.35.2 (arm-none-eabi)
2
using BFD version (2.35.2-2+14+b2) 2.35.2.
3
;@ … allein würde reichen …
4
oder:
5
;@ … ââââ …
Baut man sich ein ähnliches Listing mit ›arm-none-eabi-objdump‹ auf,
dann sieht's vernünftig aus. Allerdings fehlen dort dann die Kommentare
am Anfang des Quellcodes.
Jemand eine Idee, wie man ›arm-none-eabi-as‹ die Verwendung von utf-8
beibringen könnte?
Andreas M. schrieb:> Möglicherweise hängt es mit der LOCALE Einstellung zusammen?
Nee, leider. Das System ist durchgängig auf "de_DE.UTF-8" eingestellt.
Aber selbst Änderungen bei ›locale‹ schaffen keine Linderung.
Norbert schrieb:> Das Ding liest und verarbeitet zwar utf-8 Quelldateien problemlos,> generiert man sich allerdings ein Listing dann wird's unattraktiv:
Wie hast du das Listing denn geöffnet? Musst du vielleicht im Texteditor
einfach nur UTF-8 auswählen?
> würde
Sieht ganz klassisch so aus wie UTF-8 kodierter Text welcher
versehentlich als ISO-8859-xx interpretiert/dargestellt wird.
Niklas G. schrieb:> Wie hast du das Listing denn geöffnet? Musst du vielleicht im Texteditor> einfach nur UTF-8 auswählen?
Das ›arm-none-eabi-as‹ Listing wird verstümmelt in ISO8859-1 erzeugt.
Das ›arm-none-eabi-objdum‹ Listing wird korrekt in UTF-8 erzeugt.
1
file *.lst
2
asmfunc.lst: Non-ISO extended-ASCII text
3
asmfunc2.lst: UTF-8 Unicode text
vi sagt korrekt:
fileencoding=latin1
und fileencoding=utf-8
Andere Editoren auch. Das Listing wird tatsächlich falsch generiert.
Bauform B. schrieb:> --multibyte-handling=[allow|warn|warn-sym-only]
So etwas hat ›arm-none-eabi-as‹ nicht.
Norbert schrieb:> Das ›arm-none-eabi-as‹ Listing wird verstümmelt in ISO8859-1 erzeugt
Sieht für mich nicht so aus. Prüfe welches Encoding der Texteditor
verwendet!
Niklas G. schrieb:> Sieht für mich nicht so aus. Prüfe welches Encoding der Texteditor> verwendet!
Ich dachte das hätte ich gerade in ausreichendem Maße getan.
Bauform B. schrieb:> $ arm-none-eabi-as --multibyte-handling=warn> Assembler messages:> Fatal error: can't create a.out: Read-only file system
Hmm, neuere Version? Muss mal an den anderen Rechner und prüfen.
Bauform B. schrieb:> $ arm-none-eabi-as --multibyte-handling=warn> Assembler messages:> Fatal error: can't create a.out: Read-only file system
Verdammt. Da sitzt man so gemütlich und assemblert vor sich hin… ;-)
Bin an einen anderen Rechner gegangen:
Neuere version von ›arm-none-eabi-as‹ unterstützt nun multibyte
Warnungen.
Listing wird aber trotzdem versaubeutelt.
Und ›arm-none-eabi-objdump‹ macht's weiterhin richtig.
Da werde ich mich mit dem Fehler wohl abfinden müssen. Vielleicht lass
ich das falsch generierte Zeuch auch noch durch einen ›awk‹ laufen.
Norbert schrieb:> Ich dachte das hätte ich gerade in ausreichendem Maße getan.
Ah, die Ausgabe von vi war mir entgangen...
IMO gibt es 2 Erklärungen für das beobachtete Verhalten:
1. Der GAS interpretiert den Input-Text als ISO-8859-x und konvertiert
diesen nach UTF-8. Da der Text aber bereits UTF-8 ist, entstehen dadurch
die kaputten Zeichen.
2. Der GAS leitet die Bytes 1:1 durch, aber dein Texteditor
interpretiert das Listing als ISO-8859-x und zeigt kaputte Zeichen.
Wenn 1. der Fall wäre würde das bedeuten dass GAS Kodierungen beherrscht
und daher auch eine Option bieten sollte, den Eingabe-Charset zu ändern.
Die scheint es nicht zu geben. Dass GAS ungefragt so eine Konvertierung
vornimmt aber dabei gar nicht flexibel ist scheint mir unwahrscheinlich.
Norbert schrieb:> vi sagt korrekt:> fileencoding=latin1
Das ist eben nicht korrekt. Die Datei ist ziemlich sicher UTF-8 aber
vi erkennt dies nicht korrekt und interpretiert sie als latin1 (was das
gleiche wie ISO-8859-x ist). Das beweist, dass Erklärung 2 von oben
korrekt ist.
Wenn man "würde" als UTF-8 in eine Datei schreibt, und diese dann als
latin1=ISO8859 interpretiert, kommt "würde" heraus. Also exakt das
beobachtete Verhalten.
Ergo: Stelle VI auf UTF-8. Problem gelöst.
Der einzige Unterschied ist der Zeilenumbruch am Anfang der einen Datei.
Vielleicht hat vi ja Probleme damit, dann die Codierung richtig
automagisch zu erkennen?
Sooooo, das hat mir ja nun keine Ruhe gelassen und ich bin dem elenden
Problem ein für alle Male auf den Grund gegangen.
Zunächst einmal Herzlichen Dank für die rege Teilnahme und die guten
Ideen.
Was war es nicht:
* vi (oder andere Editoren)
* Options für ›arm-none-eabi-as‹
* Linux Filetype Erkennung.
Zu guter Letzt stellt sich nun folgendes reproduzierbar heraus:
Bei Überschreitung einer gewissen Zeilenlänge im Assembler-Sourecode
schneidet der Assembler beim Listing irgendwo hinten ab.
So weit, so gut.
Auch wenn man eine Zeile mit hunderten Zeichen hat, wird abgeschnitten.
Kein Problem.
ABER … wenn an der Schneidestelle ein UTF-8 Zeichen sitzt, dann wird
es rigoros mitten drin zerschnitten. Damit wird die Datei als
ungültige UTF-8 Datei generiert und dann natürlich später als ASCII
interpretiert.
Auch wenn man die Editoren zwingt mit UTF-8 zu arbeiten, dann erkennen
sie das ungültige Gelumpe und stellen es als Gibberish dar.
Also Fehler im ›arm-none-eabi-as‹, bei der fehlerbehafteten erzwungenen
Spaltenlimitierung. Wenn sie einfach nur dieses eine letzte Zeichen
vollständig ausgeben würden, dann wäre alles in Ordnung.**
EDIT:
** Stimmt nicht. Zeichen in der Zeile werden natürlich auch falsch
gezählt. Je nach UTF-8 Zeichen gleich mal als mehrere Bytes.
Norbert schrieb:> ABER … wenn an der Schneidestelle ein UTF-8 Zeichen sitzt, dann wird> es rigoros mitten drin zerschnitten. Damit wird die Datei als> ungültige UTF-8 Datei generiert und dann natürlich später als ASCII> interpretiert.
Ah. Das ist 'ne Erklärung.
Magst Du jetzt noch erklären, warum man Assemblerquelltext in utf-8
formatieren muss? Schreibst Du irgendein besonders internationales
Programm?
Oder verwendest Du einfach nur Umlaute im Quelltext? Dann würde
iso8859-1 völlig ausreichen ...
Harald K. schrieb:> Magst Du jetzt noch erklären, warum man Assemblerquelltext in utf-8> formatieren muss? Schreibst Du irgendein besonders internationales> Programm?
Ja.
> Oder verwendest Du einfach nur Umlaute im Quelltext? Dann würde> iso8859-1 völlig ausreichen ...
Nein.
Im Quelltext selbst wird aber entsprechend Sorge getragen das alles
korrekt abläuft.
Es geht hier zusätzlich um Dokumentation und einige sehr spezielle
Formatierungen, benötigt für Trainings. Da UTF-8 im zwanzigsten
Jahrhundert eingeführt wurde, ist das allgemeine Gefühl das man es im
einundzwanzigsten Jahrhundert durchaus schon mal verwenden kann. ›Early
adopter‹, sozusagen. ;-)
Nun wo ich das Problem kenne, habe ich bereits einen prima Würgaround in
Arbeit.
Und – wir wollen gerecht sein – es funktioniert ja auch größtenteils und
zur vollen Zufriedenheit.
Nur bei der Ausgabe des Listings sind wohl noch Routinen des zwanzigsten
Jahrhunderts verwendet worden. Das wird schon, da bin ich mir sicher.
Norbert schrieb:> Es geht hier zusätzlich um Dokumentation und einige sehr spezielle> Formatierungen, benötigt für Trainings.
Ok ... ich wär' nicht auf die Idee gekommen, daß man das in Assembler
machen will, aber bitte, man lernt ja nie aus.
Norbert schrieb:> Nur bei der Ausgabe des Listings sind wohl noch Routinen des zwanzigsten> Jahrhunderts verwendet worden.
Ich bin vermutlich nicht der einzige, der die Idee, Assemblerquelltext
in utf-8 zu verfassen, für befremdlich hält, und daher ...
Vielleicht gibt es für das Programm ja irgendwo eine
Konfigurationsmöglichkeit, wie lang Textzeilen werden dürfen, bevor sie
umgebrochen/abgeschnitten werden. Wenn ja, setze die auf einen
unwahrscheinlich hohen Wert.
Viel Erfolg!
Harald K. schrieb:> Ich bin vermutlich nicht der einzige, der die Idee, Assemblerquelltext> in utf-8 zu verfassen, für befremdlich hält, und daher ...
Das mag auf den ersten Blick so erscheinen, aber was spricht dagegen?
Es gibt eine Menge Völker auf der Welt die sich nicht ins 7Bit-ASCII
Schema zwängen möchten.
Selbst wenn der Assembler den eigentliche Source-Code in 7Bit erwarten
würde – was er nicht macht, er kann UTF-8 – wenigstens die Ausgabe eines
Listings sollte doch im Jahre 2024 keine solch trivialen Fehler mehr
verursachen.
1
2
.text
3
.func test1
4
.align 2
5
test1:
6
.string "─────────────"
7
.string "ABC äöü ÄÖÜ ß"
8
.string "─────────────"
9
.endfunc
Übersetzt UTF-8 Strings einwandfrei.
Funktioniert perfekt und resultiert in einem Listing:
Norbert schrieb:> Also Fehler im ›arm-none-eabi-as‹, bei der fehlerbehafteten erzwungenen> Spaltenlimitierung. Wenn sie einfach nur dieses eine letzte Zeichen> vollständig ausgeben würden, dann wäre alles in Ordnung.**
Das ist doch eine prima Basis dafür, dass du zumindest einen Bugreport
schreiben kannst. Wenn du paar freie CPU-Zyklen im Gehirn hast, kannst
du natürlich auch gleich noch einen Patch liefern, der zumindest das
Schlimmste Übel beseitigt. ;-)
Jörg W. schrieb:> Das ist doch eine prima Basis dafür,
Jörg, bis ich mich in die GNU Compiler Collection eingelesen hätte, also
so das ich etwas vernünftiges beisteuern könnte…
Und da dieses spezielle Verhalten des Assemblers wohl bisher nur wenigen
aufgefallen und überdies definitiv kein Show-Stopper ist, werde ich mir
nach dieser ergiebigen Diskussion ein Tool bauen welches aus den beiden
Listings ein Kombiniertes mit UTF-8 erzeugt. Wesentlich weniger Aufwand.
Und der eigentliche Assembler muss auch nicht angefasst werden.
Norbert schrieb:> Jörg W. schrieb:>> Das ist doch eine prima Basis dafür,>> Jörg, bis ich mich in die GNU Compiler Collection eingelesen hätte, also> so das ich etwas vernünftiges beisteuern könnte…
Mit GCC hat das nichts zu tun.
Der Assembler ist Teil der Binutils, und du hast einen prima Testcase,
mit dem sich der Bug reproduzieren lässt.
> Und da dieses spezielle Verhalten des Assemblers wohl bisher nur wenigen> aufgefallen und überdies definitiv kein Show-Stopper ist
Wenn alle so denken würden, würden Bugs ewig drin bleiben, obwohl sie
schon jemand gefunden hat.
Norbert schrieb:> Na dann muss ich mir die Tage mal das binutils-source package ansehen.> Mal schauen…
Brauchst nicht, Jörg hat einen Bugreport für Dich gemacht :-)
Natürlich kann er sich trotzdem den Sourcecode noch ansehen und schauen,
ob der Bugfix vielleicht gar nicht so kompliziert ist.
Zumindest ist der Bug damit erstmal verewigt. Der Testcase war nun so
schwer nicht zu produzieren, Norberts Beschreibung genügte.
Wen es interessiert, aus
1
# This is a very lengthy comment that contains lots of strange characters x±™⅝⅝⅜£⅜¤⅜ĦĦŊĦŊŊ⅛£⅜⅛⅜⅛£⅜£⅜£
wird im Listing (je nach demnjenigen, der den Datenmüll darstellt)
sowas:
1
3 # This is a very lengthy comment that contains lots of strange characters xﾂｱ邃｢竇昶慊｣竇慊､竇
Thread beobachten
Seitenaufteilung abschalten