GNU AS UTF-8 Software-Unschärfe

Möglicherweise hängt es mit der LOCALE Einstellung zusammen?

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.

1

export LC_ALL=C && make -B

2

export LC_ALL=C.UTF-8 && make -B

3

export LC_ALL=de_DE.UTF-8 && make -B

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.

Meine manual page meint, du könntest mal diese Option probieren:

1

--multibyte-handling=[allow|warn|warn-sym-only]

wobei ich =warn bevorzugen würde. Assembler mit Unicode, denkt denn niemand an den Denkmalschutz?

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.

Gibt es beim von objdump erzeugten Listing evtl. einen BOM den es beim von as erzeugten nicht gibt? Was sagt

1

head asmfunc.lst| hexdump -C

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.

Schöner Gedanke. Keine Marker.

1

$hexdump -C <asmfunc.lst  | head -n5

2

 hexdump -C <asmfunc.lst  | tail -n5

3

 hexdump -C <asmfunc2.lst | head -n5

4

 hexdump -C <asmfunc2.lst | tail -n5

5

00000000  20 47 4e 55 20 61 73 73  65 6d 62 6c 65 72 20 76  | GNU assembler v|

6

00000010  65 72 73 69 6f 6e 20 32  2e 33 35 2e 32 20 28 61  |ersion 2.35.2 (a|

7

00000020  72 6d 2d 6e 6f 6e 65 2d  65 61 62 69 29 0a 09 20  |rm-none-eabi).. |

8

00000030  75 73 69 6e 67 20 42 46  44 20 76 65 72 73 69 6f  |using BFD versio|

9

00000040  6e 20 28 32 2e 33 35 2e  32 2d 32 2b 31 34 2b 62  |n (2.35.2-2+14+b|

10

00002f70  63 2e 53 3a 31 35 32 20  20 20 20 2e 74 65 78 74  |c.S:152    .text|

11

00002f80  3a 30 30 30 30 30 30 30  30 30 30 30 30 30 30 62  |:00000000000000b|

12

00002f90  61 20 24 74 0a 0a 4e 4f  20 55 4e 44 45 46 49 4e  |a $t..NO UNDEFIN|

13

00002fa0  45 44 20 53 59 4d 42 4f  4c 53 0a                 |ED SYMBOLS.|

14

00002fab

15

00000000  0a 61 73 6d 66 75 6e 63  2e 6f 3a 20 20 20 20 20  |.asmfunc.o:     |

16

00000010  66 69 6c 65 20 66 6f 72  6d 61 74 20 65 6c 66 33  |file format elf3|

17

00000020  32 2d 6c 69 74 74 6c 65  61 72 6d 0a 0a 53 59 4d  |2-littlearm..SYM|

18

00000030  42 4f 4c 20 54 41 42 4c  45 3a 0a 30 30 30 30 30  |BOL TABLE:.00000|

19

00000040  30 30 30 20 6c 20 20 20  20 64 20 20 2e 74 65 78  |000 l    d  .tex|

20

000023b0  3b 40 20 67 65 74 73 20  30 78 33 61 62 62 63 63  |;@ gets 0x3abbcc|

21

000023c0  64 64 20 69 6e 74 6f 20  72 30 0a 20 20 63 61 3a  |dd into r0.  ca:|

22

000023d0  09 36 38 37 38 20 20 20  20 20 20 09 6c 64 72 09  |.6878      .ldr.|

23

000023e0  72 30 2c 20 5b 72 37 2c  20 23 34 5d 0a           |r0, [r7, #4].|

24

000023ed

asmfunc.lst ist das Ejakulat des ›arm-none-eabi-as‹ asmfunc2.lst der des ›arm-none-eabi-objdump‹

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:

1

 GNU assembler version 2.35.2 (arm-none-eabi)

2

   using BFD version (2.35.2-2+14+b2) 2.35.2.

3

 options passed  : -mcpu=cortex-m0plus -march=armv6-m -mthumb -warn --fatal-warnings -k -g -acghlns=ttt.lst 

4

 input file      : ttt.S

5

 output file     : ttt.o

6

 target          : arm-none-eabi

7

 time stamp      : 2024-08-12T17:10:36.000+0200

8

9

   1                        .text

10

   2                        .func   test1

11

   3                        .align  2

12

   4                test1:

13

   5                

14

   6 0000 E29480E2           .string "─────────────"

15

   6      9480E294 

16

   6      80E29480 

17

   6      E29480E2 

18

   6      9480E294 

19

   7 0028 41424320           .string "ABC äöü ÄÖÜ ß"

20

   7      C3A4C3B6 

21

   7      C3BC20C3 

22

   7      84C396C3 

23

   7      9C20C39F 

24

   8 003d E29480E2           .string "─────────────"

25

   8      9480E294 

26

   8      80E29480 

27

   8      E29480E2 

28

   8      9480E294 

29

   9                        .endfunc

30

  10                

31

  11 0065 00C046     

32

DEFINED SYMBOLS

33

               ttt.S:4      .text:0000000000000000 test1

34

               ttt.S:6      .text:0000000000000000 $d

35

               ttt.S:11     .text:0000000000000065 $d

36

               ttt.S:11     .text:0000000000000066 $t

37

38

NO UNDEFINED SYMBOLS

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. ;-)

Norbert schrieb:

Funktioniert perfekt und resultiert in einem Listing:

Wo ist denn da was abgeschnitten?

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.

https://sourceware.org/bugzilla/show_bug.cgi?id=32077

Na dann muss ich mir die Tage mal das binutils-source package ansehen. Mal schauen…

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ﾂｱ邃｢竇昶慊｣竇慊､竇