Forum: Compiler & IDEs DWARF error: invalid abstract instance DIE ref


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 Veit D. (devil-elec)


Lesenswert?

Hallo,

ich baue gerade eine neue Lib, zusätzlich zu bestehenden Libs, die alle 
eingebunden werden. Mit 2 Methoden in der neuen Lib ist noch alles i.O. 
Füge ich eine Dritte hinzu erhalte ich:
C:\avrToolchain\avr-gcc-10.2.0_mingw64_binutils2.35/bin/avr-objdump: 
DWARF error: invalid abstract instance DIE ref

Kann es sein das avr-objdump ab einer gewissen Codegröße bzw. Anzahl an 
Libs mit virtuellen Methoden nicht mehr klar kommt? Der Compiler selbst 
meckert nicht. Flash 9200 und RAM 670 Bytes. Controller ist ein 
AVR128DB48.

Die DWARF Meldung hatte ich sonst immer sporadisch. Beim erneuten 
kompilieren war sie dann weg. Diesmal erscheint sie immer.

Muss ich mir Sorgen machen?

: Verschoben durch Moderator
von pegel (Gast)


Lesenswert?

avr-objdump hat doch etliche Parameter.
Ist da nichts dabei was mehr Informationen gibt?

Was macht z.B.: --dwarf[=...] ?

von Veit D. (devil-elec)


Lesenswert?

Hallo,

hmm, avr-objdump direkt in der Konsole aufgerufen (ohne .bat) 
funktioniert. Verstehe ich nicht.

Die Option Bsp. --dwarf[=rawline] kennt es nicht, ist unbekannt.
-W funktioniert jedoch.

von pegel (Gast)


Lesenswert?

Veit D. schrieb:
> avr-objdump direkt in der Konsole aufgerufen (ohne .bat)
> funktioniert.

Kann es sein, dass durch viele Kerne und Parallel Abarbeitung der 
Prozesse etwas anderes noch nicht fertig ist?

Das würde das gelegentliche Auftreten des Fehlers erklären.

Setz doch einfach mal eine Sekunde Pause vor avr-objdump in der .bat .

von Veit D. (devil-elec)


Lesenswert?

Hallo,

habe den Code zusammengelegt und Einzeiler zum besseren auskommentieren 
gemacht. Wenn ich die Methode deleteOVF() auskommentiere kommt kein 
DWARF Error. Damit man einmal sieht um welchen Codesyntax es sich 
handelt. Am Ende möchte ich das tcb Array nutzen um über alle Timer 
mittels for Indexdurchlauf drüberzugehen.
Ich probiere einmal die Pause.
1
#pragma once
2
 
3
#define INLINE inline __attribute__((always_inline))
4
5
namespace AVR128DB 
6
{ 
7
  namespace TCB 
8
  { 
9
    namespace
10
    {        
11
      using Register = volatile uint8_t *;
12
      
13
      #if defined(__AVR_AVR128DB48__)
14
        #include <AVR128DB48_TCBnRegister.h>  
15
      #else
16
        #error "Your board has no AVR128DB48 controller!".
17
      #endif
18
      constexpr Register getCTRLA(const uint8_t n) {
19
        return (Register) (baseAddr[n].baseAddr + addrOffset.ctrla);
20
      }
21
      constexpr Register getINTFLAGS(const uint8_t n) {
22
        return (Register) (baseAddr[n].baseAddr + addrOffset.intflags);
23
      }
24
25
    template<const uint8_t numberTCBn>
26
    class Timer 
27
    {         
28
      public:
29
        void INLINE enable()    { *getCTRLA(numberTCBn) = *getCTRLA(numberTCBn) | TCB_ENABLE_bm; }       
30
        void INLINE disable()   { *getCTRLA(numberTCBn) = *getCTRLA(numberTCBn) & ~TCB_ENABLE_bm; }            
31
        void INLINE deleteOVF() { *getINTFLAGS(numberTCBn) = *getINTFLAGS(numberTCBn) | TCB_OVF_bm; }     
32
    };
33
    
34
    class TimerInterface  // Interface
35
    {
36
      public:
37
        virtual void enable() = 0;
38
        virtual void disable() = 0;     
39
        virtual void deleteOVF() = 0; 
40
    };
41
42
    template<uint8_t n>
43
    class Tcb : public TimerInterface
44
    {
45
      private:
46
        Timer<n> tcb;
47
48
      public:
49
        virtual void enable()     { tcb.enable(); }  
50
        virtual void disable()    { tcb.disable(); } 
51
        virtual void deleteOVF()  { tcb.deleteOVF(); }   
52
    };
53
    
54
    TimerInterface *tcb[4] =
55
    {
56
      new Tcb <0>(),   // TCB0
57
      new Tcb <1>(),   // TCB1
58
      new Tcb <2>(),   // TCB2
59
      new Tcb <3>(),   // TCB3
60
    };
61
  } 
62
}

von Veit D. (devil-elec)


Lesenswert?

Hallo,

deine Erklärung mit den mehreren Kernen usw. macht erstmal Sinn. Pause 
einbauen klappt erstmal nicht wie gedacht, wird einfach ignoriert.
Die Arduino IDE ruft eine Textdatei mit "Hunderten" Compilerparametern 
zum kompilieren auf. Darin steckt am Ende ein Aufruf für avr-objdump der 
sich mittels .bat die Info zum Pfad der kompilierten Dateien im Temp 
Ordner holt. Unterbricht man das anderweitig ist die Pfadinfo weg.
Mal sehen ob mir dazu eine Lösung einfällt. Der Weg scheint der richtige 
zu sein, wenn es separat in der Konsole funktioniert. Danke schon 
einmal.

von Veit D. (devil-elec)


Angehängte Dateien:

Lesenswert?

Hallo,

passend zum erneut aufgetauchten DWARF Problem
Beitrag "Re: Arduino Uno Serial stört Timer1 Interrupts?"
mach ich einmal hier weiter.

Diesmal kann ich die .elf Datei auch nicht nachträglich in der Konsole 
fehlerfrei disasemblieren. Erhalte genau die gleichen Fehler als wenn 
das die Arduino IDE selbst gleich mit erledigt. avr-gcc 10.2 & binutils 
2.35

Nehme ich avr-objdump.exe aus meiner avr-gcc 10.1 & binutils 2.34 
Toolchain gibts auch bei mir keine Fehler. Deswegen schließe ich ein 
Timing Problem mit den CPU Kernen/Threads vorläufig aus. Ich werde im 
laufe des Tages noch eine Toolchain mit gcc 10.2 und binutils 2.34 bauen 
und nochmal testen.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

erste Gegenprobe mit avr-gcc-10.2.0 & binutils 2.34 zeigt keine 
Disasemblierungsfehler. Egalb ob Wire.h inkludiert ist oder nicht.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

zweite Gegenprobe mit avr-gcc-10.1.0 & binutils 2.35 zeigt erneut DWARF 
Errors wenn Wire.h inkludiert wird. 'grübel'

Erste Erkenntnis die sich gefestigt hat ist. Es gibt ein Problem im 
Zusammenspiel der Wire.h mit binutils v2.35.

1
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 15ee
2
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 15fa
3
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 1606
4
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 1612
5
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 161e
6
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 162a
7
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 1636
8
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 1642
9
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 164e
10
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 165a

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

habe mir noch eine Toolchain aus avr-gcc 9.3 und binutils 2.35 gebaut. 
Sobald ich Wire.h inkludiere wirft es wieder DWARF Errors.
Mir scheint es gibt wirklich ein Problem mit der binutils Version 2.35.

von pegel (Gast)


Lesenswert?

Also ehrlich gesagt, wenn Du alles selber baust und keine getestete 
Toolchain benutzt, kannst Du nicht erwarten, dass zum speziellen Problem 
irgendwer eine Antwort parat hat.

Ist jedenfalls meine Meinung...

von Veit D. (devil-elec)


Lesenswert?

Hallo,

das ist jetzt irgendwie falsche Welt oder? Wer soll die Toolchain 
testen? Zeige mir eine avr-gcc Toolchain mit binutils 2.35 und ich 
probiere sie aus. Wie testest du deine Toolchains? Jetzt gibts ein 
Problem sobald binutils 2.35 verwendet wird und ich soll nicht fragen 
dürfen. Das finde ich merkwürdig.

: Bearbeitet durch User
von pegel (Gast)


Lesenswert?

So habe ich das nicht gemeint.

Ich würde einfach die aktuellste offizielle verwenden, die dann auch für 
gut befunden wurde.

Wenn Du das Neueste von allem haben willst, liegt die Verantwortung 
dafür bei dir selbst.

von pegel (Gast)


Lesenswert?

Für Linux scheinen die Versionen:

avr-binutils 2.35.1-1
https://www.archlinux.org/packages/community/x86_64/avr-binutils/

und

avr-gcc 10.2.0-1
https://www.archlinux.org/packages/community/x86_64/avr-gcc/

aktuell zu funktionieren.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

genau das ist ja das Problem. Welche sieht man als offiziell getestet 
an? Nach welchen Kriterien geht man?
Die Toolchain der Arduino IDE ist auf dem Stand avr-gcc 7.x
Die Toolchain von Atmel Studio 7 ist auf dem Stand avr-gcc 4.9.x
Zudem gibts ja kein Problem mit der Toolchain selbst, sondern beim 
disasemblieren mittels obj-dump. Betrifft also nur eine Winzigkeit der 
gesamten Toolchain. Kann man erstmal beheben wenn man eine ältere 
obj-dump.exe verwendet. Ist erstmal nichts dramatisches. Ich wollte es 
dennoch melden falls es noch niemand festgestellt haben sollte.
Ich weiß das Jörg W. hier aus dem Forum sich um die binutils kümmert. 
Vielleicht hat er einen Tipp vielleicht auch nicht. Werde ich ja 
mitbekommen. Ansonsten bleibts erstmal im Raum stehen bis die Lösung 
kommt.

Hatte übrigens übersehen das es schon eine binutils 2.35.1 gibt. Also 
nochmal eine mit avr-gcc 10.2.0 gebaut. DWARF Errors bleiben leider 
bestehen. Das am Rande.

Edit: Dafür hat irgendwer die avr-size.exe gefixt. Die funktioniert 
nämlich wieder nachdem sie über Versionen hinweg nicht funktionierte. 
:-)  Danke.

: Bearbeitet durch User
von Veit D. (devil-elec)


Lesenswert?

Hallo,

es gibt noch eine Abhängigkeit. Kompiliert man mit C++17 statt C++20 
gibts keine DWARF Errors mit Wire.h.

Am Rande. Das mit der gefixten avr-size.exe stimmt natürlich nicht. 
Sorry. War gestern schon spät, hab mich von der Arduino IDE ablenken 
lassen. Die nutzt das ja nicht. Atmel Studio greift noch darauf zurück.

von Veit D. (devil-elec)


Lesenswert?

pegel schrieb:
> Für Linux scheinen die Versionen:
>
> avr-binutils 2.35.1-1
> https://www.archlinux.org/packages/community/x86_64/avr-binutils/
>
> und
>
> avr-gcc 10.2.0-1
> https://www.archlinux.org/packages/community/x86_64/avr-gcc/
>
> aktuell zu funktionieren.

Bei Arch bekommt man immer die aktuellsten Versionen. Die prüft jedoch 
auch niemand weiter. Der Maintainer pflegt das Paket ein, mehr nicht. 
Ich baue nur mit Release Versionen. Ob das -1 am Ende auf Snapshots 
hindeutet kann ich nicht sagen. Ich glaube jedoch nicht das Arch soweit 
geht und Snapshots bzw. Beta Versionen einpflegt. Von daher wäre ich und 
Arch auf dem gleichen Stand.

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


Lesenswert?

Ich habe die Arduino-Umgebung nicht zur Hand.

Kannst du hier mal ein ELF-File hinlegen, welches das Problem hat?

Was mir bei Lesen des Threads nicht ganz klar ist: funktioniert das sich 
ergebende ELF-File eigentlich? Ist es also nur ein Problem mit objdump, 
oder ist da noch tiefer was kaputt?

von Veit D. (devil-elec)



Lesenswert?

Hallo,

ich habe den Sketch 2x kompiliert. Einmal mit binutils 2.34 und einmal 
mit 2.35.1. Jeweils mit avr-gcc 10.2.0. Geht aus dem Dateinamen hervor. 
Laut meinen Tests spielt die avr-gcc Version keine Rolle.

Ein zeitliches Problem durch Multithreading kann ich mittlerweile 
ausschließen, da der DWARF Error auch beim nachträglichen diassemblieren 
der .elf Datei auftritt. Laut meiner Meinung betrifft das die 
obj-dump.exe der binutils 2.35.x
Ich kann beide .elf Dateien mit der obj-dump.exe der binutils 2.34 
fehlerfrei disassemblieren.
Mit der obj-dump.exe von 2.35 oder 2.35.1 erhalte ich DWARF Errors.

Die Kompilierung selbst erzeugt keine Fehler, auch keine Warnungen und 
das erzeugte Programm funktioniert.

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


Lesenswert?

Ich habe diese neue Version gerade noch nicht greifbar. Aber ich denke, 
du hast das damit schon so weit eingekreist, dass du dafür eigentlich 
direkt bei den binutils ein Bug-Ticket öffnen kannst, an das du deine 
beiden ELF-Dateien dran hängst.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

Danke fürs lesen. Ich werde mein Besten geben ...

von Veit D. (devil-elec)


Lesenswert?

Hallo,

das Ergebnis vom Bugreport lautet, es ist im aktuellen binutils 
Entwicklungszweig gefixt.

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


Lesenswert?

OK, also ein echter "Bug zwischendurch". Shit happens.

von Veit D. (devil-elec)


Lesenswert?

Hallo,

genau, zur falschen Zeit am falschen Ort - oder so ähnlich treffend. 
:-)
Ich warte brav auf das nächste Release.

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]
  • [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.