DWARF error: invalid abstract instance DIE ref

[Veit D. (devil-elec)]

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?

[pegel (Gast)]

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

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

[Veit D. (devil-elec)]

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.

[pegel (Gast)]

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 .

[Veit D. (devil-elec)]

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.

#pragma once
 
#define INLINE inline __attribute__((always_inline))

namespace AVR128DB 
{ 
  namespace TCB 
  { 
    namespace
    {        
      using Register = volatile uint8_t *;
      
      #if defined(__AVR_AVR128DB48__)
        #include <AVR128DB48_TCBnRegister.h>  
      #else
        #error "Your board has no AVR128DB48 controller!".
      #endif
      constexpr Register getCTRLA(const uint8_t n) {
        return (Register) (baseAddr[n].baseAddr + addrOffset.ctrla);
      }
      constexpr Register getINTFLAGS(const uint8_t n) {
        return (Register) (baseAddr[n].baseAddr + addrOffset.intflags);
      }

    template<const uint8_t numberTCBn>
    class Timer 
    {         
      public:
        void INLINE enable()    { *getCTRLA(numberTCBn) = *getCTRLA(numberTCBn) | TCB_ENABLE_bm; }       
        void INLINE disable()   { *getCTRLA(numberTCBn) = *getCTRLA(numberTCBn) & ~TCB_ENABLE_bm; }            
        void INLINE deleteOVF() { *getINTFLAGS(numberTCBn) = *getINTFLAGS(numberTCBn) | TCB_OVF_bm; }     
    };
    
    class TimerInterface  // Interface
    {
      public:
        virtual void enable() = 0;
        virtual void disable() = 0;     
        virtual void deleteOVF() = 0; 
    };

    template<uint8_t n>
    class Tcb : public TimerInterface
    {
      private:
        Timer<n> tcb;

      public:
        virtual void enable()     { tcb.enable(); }  
        virtual void disable()    { tcb.disable(); } 
        virtual void deleteOVF()  { tcb.deleteOVF(); }   
    };
    
    TimerInterface *tcb[4] =
    {
      new Tcb <0>(),   // TCB0
      new Tcb <1>(),   // TCB1
      new Tcb <2>(),   // TCB2
      new Tcb <3>(),   // TCB3
    };
  } 
}

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

Hallo,

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

[Veit D. (devil-elec)]

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.

C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 15ee
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 15fa
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 1606
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 1612
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 161e
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 162a
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 1636
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 1642
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 164e
C:\avrToolchain\avr-gcc-10.1.0_mingw64_binutils2.35/bin/avr-objdump: DWARF error: could not find variable specification at offset 165a

[Veit D. (devil-elec)]

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.

[pegel (Gast)]

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

[Veit D. (devil-elec)]

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.

[pegel (Gast)]

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.

[pegel (Gast)]

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.

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

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.

[Veit D. (devil-elec)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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?

[Veit D. (devil-elec)]

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.

[Jörg W. (dl8dtl) (Moderator)]

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.

[Veit D. (devil-elec)]

Hallo,

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

[Veit D. (devil-elec)]

Hallo,

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

[Jörg W. (dl8dtl) (Moderator)]

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

[Veit D. (devil-elec)]

Hallo,

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