grep-ähnliches Werkzeug gesucht

Du kannst ja deinen Quelltext nur durch den Präprozessor jagen (cpp), 
ohne anschließend zu compilieren. Dann hast du alles in einer Datei, was 
sonst durch den Compiler gedreht würde.

Nennt sich moderne IDE.
Eclipse sollte sowas bieten, in Java funktioniert sowas wie "Open 
Declaration" oder "Open Type Hierarchie", "Open Call Hierarchie" 
einwandfrei.

Nachtrag: Gute Editoren wie Notepad++ oder EM-Editor bieten oft auch 
ungeahnte Möglichkeiten wenn man sich malintensiver mit ihnen 
beschäftigt.

Ingo W. schrieb:
> Du kannst ja deinen Quelltext nur durch den Präprozessor jagen (cpp),
> ohne anschließend zu compilieren. Dann hast du alles in einer Datei, was
> sonst durch den Compiler gedreht würde.

Das hilft leider nicht, weil die #defines aufgelöst werden und nur noch 
deren Wert in der cpp-Ausgabe steht.

René H. schrieb:
> Welches Betriebssystem?

Linux

> Ingos Vorschlag ist das was Du brauchst.

Beitrag "Re: grep-ähnliches Werkzeug gesucht"

René H. schrieb:
> Weshalb dürfen #defines nicht aufgelöst werden, was ist dein Ziel genau?

Ich habe ein Problem mit einem #define, dessen Definition auf 
merkwürdige Weise verschütt geht - die Spuren des Unfalls würden vom 
Preprozessor verwischt und ich bin so schlau wie vorher.

Mit einem grep, der statt durch einen Verzeichnisbaum durch die 
#include-Hierarchie sucht, könnte man nach dem Symbol suchen und hätte 
dann vermutlich schnell die Stelle gefunden, an der der Unfall passiert.

Lediglich #defines, die in #include-Anweisungen benutzt werden, müssten 
natürlich genau aufgelöst werden, um den Weg durch die #includes korrekt 
zu finden.

Schreib dir doch schnell ein Bash-Skript? Du könntest im ersten File das 
#define suchen, und falls nicht gefunden suchst du nach #include, nimmst 
den dateinamen und jagst den wieder durch grep, usw. bis dein #define 
gefunden ist. Mit einer Kombination aus sed/grep/awk sollte das 
Problemlos lösbar sein.

Das Ganze ist etwas kompliziert:

Ich habe einen Simulator für einen MLT-BT05 Bluetooth Low Energy-Adapter 
gebastelt, mit dem ich meine avr-Module ohne Änderungen im Code unter 
Linux testen kann.

Das Problem dabei sind die avr-Header in diesen Source-Files.

Die trickse ich mit einem kleinen Header aus, der unter der Bedingung 
#if SIMULATION eingelesen wird. U.a. definiert er die Symbole der Bauart 
AVR_INTERRUPT_H, die verhindern, dass der Inhalt des entsprechenden 
avr-Headers wirksam wird. (Das dient normalerweise dazu, Fehler durch 
das mehrfache #includen eines Headers zu unterdrücken.)

Außerdem werden einige Symbole aus den avr-Headern definiert, die für 
die Simulation gebraucht werden.

In der Software, die simuliert werden soll, steht folgende Definition:

1

enum UARTError {

2

    UART_Escape      = 1,

3

    UART_DataOverrun = 1 << DOR0,

4

    UART_FrameError  = 1 << FE0,

5

    UART_ParityError = 1 << UPE0

6

};

Die Symbole werden im Simulations-Header definiert als:

1

#define UPE0 2

2

#define DOR0 3

3

#define FE0 4

Nach diesem Header werden die üblichen avr-Header #includet.

Das seltsame ist nun, dass der Compiler DOR0 und FE0 kennt, nicht aber 
UPE0. (Wenn ich die letzte Zeile im enum auskommentiere, gibt es keinen 
Fehler mehr.)

Solche Gurken zu finden, ist wirklich ein ganz übler Job - mit so einem 
grep-ähnlichen Werkzeug könnte man das stark vereinfachen.

Silvano C. schrieb:
> Schreib dir doch schnell ein Bash-Skript?

Bei solchen Dingen steckt der Teufel im Detail - das kriegt man 
erfahrungsgemäß nicht mal eben schnell hin ;-)

Bash ist dazu wohl am wenigsten von allen Skriptsprachen geeignet…

Arno schrieb:
> Wenn du die anderen #defines in deinem Simulations-Header
> auskommentierst, was passiert dann?

1

error: ‘DOR0’ undeclared here (not in a function)

2

error: ‘FE0’ undeclared here (not in a function)

Wie zu erwarten war. (Die 3 Zeile ist auskommentiert.)

Und jetzt wirds ganz komisch:
Wenn die 3. Zeile nicht auskommentiert ist, verschwinden die beiden 
Fehlermelungen und stattdessen wird

1

error: ‘UPE0’ undeclared here (not in a function)

angezeigt…

So, und jetzt kommt der Oberhammer :

Ich benutze Code::Blocks 16.01 als IDE. Die habe ich eben beendet und 
neu gestartet und oh Wunder: Die Simulation compiliert jetzt auch mit 
nicht auskommentierter 3. Zeile im enum.

Wie sowas passieren kann, ist mir völlig schleierhaft.

Helfen dir die GCC-Optionen -E -dU vielleicht?

Wie gesagt, das Problem hat sich durch Neustart von CB in Luft aufgelöst 
- warum auch immer.

Jörg W. schrieb:
> Helfen dir die GCC-Optionen -E -dU vielleicht?

Wo finde ich denn die Beschreibung dafür? (Im man-Eintrag für gcc ist -d 
zwar erwähnt (zweimal "see above"), aber die Beschreibung für -d fehlt.

OT: Was für ein Vollpfosten hat denn gerade über alle meine Beiträge je 
einen Miesen vergeben?

Uhu U. schrieb:

> Wo finde ich denn die Beschreibung dafür?

Ich habe sie in der man page gefunden:

1

       -dCHARS

2

…

3

           U   Like D except that only macros that are expanded, or whose

4

               definedness is tested in preprocessor directives, are

5

               output; the output is delayed until the use or test of the

6

               macro; and #undef directives are also output for macros

7

               tested but undefined at the time.

guest schrieb:
> Uhu U. schrieb:
>> Wo finde ich denn die Beschreibung dafür? (Im man-Eintrag für gcc ist -d
>> zwar erwähnt (zweimal "see above"), aber die Beschreibung für -d fehlt.
>
> https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html#index-dU

OK, in der aktuellen man page ist das etwas sinnvoller umformuliert, 
sodass man direkt nach -dU suchen kann.

Falls das nicht hilft, müsstest du dir einen Compiler selbst bauen und 
dann in der Datei libcpp/directives.c halt eine generelle Warnung 
generieren lassen für jedes #undef, was verarbeitet wird.

Jörg W. schrieb:
> Helfen dir die GCC-Optionen -E -dU vielleicht?

Ja, die ist bei solchen Problemen wohl nützlich - die Definitionen 
werden bei Benutzung angezeigt.


Wie so ein Problem durch die IDE entstehen kann, ist mir rätselhaft… Ich 
hatte mich in den letzten Tagen schon öfters mit so komischen Effekten 
rumgeärgert, die sich dann plötzlich in Luft auflösten.

Ganz übel ist. dass CB 16.01 für avr-gcc unter Linux automatisch den 
include-Pfad /usr/include in die Compileraufrufe einbaut. Das ist zwar 
leicht zu reparieren - wenn man weiß wie. (Man muss die Einstellung in 
~/.config/codeblocks/default.conf reparieren - falls jemand dasselbe 
Problem hat und sich hierherverlaufen sollte.)

Jörg W. schrieb:
> Falls das nicht hilft, müsstest du dir einen Compiler selbst bauen und
> dann in der Datei libcpp/directives.c halt eine generelle Warnung
> generieren lassen für jedes #undef, was verarbeitet wird.

#undef erscheint auch im gcc -E -dU - Listing. Man sollte derartiges 
also finden können, wenn es denn in den verarbeiteten Quelltexten steht.

Uhu U. schrieb:
> #undef erscheint auch im gcc -E -dU - Listing.

Yep, aber wenn du einen modifizierten Compiler gleich Dateinamen und 
Zeilennummer eines jeden #undef per cpp_error() ausgeben lässt, sollte 
es sich sehr viel einfacher finden lassen.

Der Code steht in einer Funktion namens do_undef(). Im Prinzip musst du 
vermutlich nur hier:

1

      if (node->type == NT_MACRO)

2

        {

3

          if (node->flags & NODE_WARN)

4

            cpp_error (pfile, CPP_DL_WARNING,

5

                       "undefining \"%s\"", NODE_NAME (node));

die Bedingung "if (node->flags & NODE_WARN)" auskommentieren.

Ich werde heute Nacht mal den Memorytest laufen lassen…

Nano schrieb:
> IDEs kennen den Code und bieten so eine rekursive Suche in den include
> Dateien eigentlich auch an.

CB kann Headerdateien mit einem Klick öffnen - aber damit so einem 
Problem nachgehen? Da kannst du klicken, bis du schwarz wirst…

Es sieht so aus, als sei irgendwo der Wurm in der Hardware: der 
Memorytest löst kurz nach dem Start einen Reboot aus.

:-((

Es wird wohl langsam Zeit, dass Mainboards für normale PCs lernen auch 
mit ECC-Speicher zurecht zu kommen…

Paritätsbits waren früher™ ja völlig normal. Als man dann vier 9bittige 
Riegel zu 32 Bit parallel geschaltet hat, konnte man mit den 4 übrigen 
Bits eine ECC implementieren.

Später kamen dann die Sparfüchse …

Wir hatten in der DDR so einen Spruch: Spare um jeden Preis – koste es, 
was es wolle. Genau das passiert halt hier.

Jörg W. schrieb:
> Spare um jeden Preis – koste es, was es wolle.

Dann habt ihr also Schäuble und Draghi in einer Person quasi vorweg 
genommen.

Bisher startete Linux Mint 17 nach dem Einschalten mit einem Graphischen 
Bildschirm für die Passphrasen-Eingabe. Seit einigen Tagen kommt 
stattdessen sofort das Grub-Boot-Menü. Das sind lauter so kleine 
Hinweise, dass da irgendwo der Holzwurm am Nagen ist.

Das mit dem RAM Ein- und Ausbauen ist eine gute Idee.

Nun habe ich die Hardware mal etwas unter die Lupe genommen - das Bild 
ist verwirrend:

Als erste die beiden 8 GB Speicherriegel raus genommen und wieder 
reingsteckt. Memorytest angeworfen - wieder ist er sofort abgestürzt.

Dann die Speicherriegel vertauscht und oh Wunder, der Memorytest lief 
durch und das ohne Fehler in 2 h. Dabei hat er einen kompletten 
Durchlauf geschafft und einen zweiten angefangen.

Dann mit ESC abgebrochen und versucht, zu booten - ging nicht, Platte 
nicht erkannt.

Platte raus und wieder rein - dasselbe. Erst nach einigen Startversuchen 
und an den Steckern und Strippen am MB rumnesteln ist es gelungen, ins 
Bios zu kommen und über das Bootmenü dort die Platte neu auszuwählen.

Dann endlich ins grub-Bootmenü und nochmal den Memorytest ausgewählt - 
wieder stürzt er sofort ab - wohlgemerkt mit vertauschten 
Speicherriegeln.

Nächster Anlauf und Linux gebootet - jetzt läuft die Mühle.

Diagnose? Keine Ahnung. Nun fragt sich, was weiter tun.

oszi40 schrieb:
> CR2032 <2,5V=? Tauschen

Hat die noch eine andere Funktion, als die batteriegepufferte RTC zu 
versorgen?

Das Netzteil hat ohne Last folgende Ripple (jeweils Maximalwerte)

3.3 V: 70 mV (1%:  33 mV)
5 V:   80 mV (1%:  50 mV)
12 V:  60 mV (1%: 120 mV)

Das Netzteil ist also augelutscht… Zum Glück habe ich schon vor einiger 
Zeit ein Reservenetzteil beschafft.

---

So, das neue Netzteil ist eingebaut, nur der Memorytest stürzt immernoch 
sofort ab.

Die CR2032 hat noch 3.04 V.

Der Memorytest tuts jetzt plötzlich wieder, sogar, nachdem ich die 
RAM-Riegel wieder zurückgetauscht habe.

Die Elkos sehen gut aus.

Ein VirualBox VM ging in GuruMeditation - da ging irgendwas oberschief. 
Man konnte sie zwar zurücksetzten, aber nach dem nächsten Boot 
wiederholte sich das Spiel.

Mit zurückgespieltem Backup läuft sie jetzt wieder.

Nachtrag: das zurückspielen hat leider doch nichts gebracht - die VM 
hängt schon wieder.

Jetzt soll erstmal der Memorytest gründlich testen. Beim Start ist 
aufgefallen, dass er jetzt die 3 Caches anzeigt - beim ersten Lauf nach 
dem RAM-Riegeltausch waren die Stellen auf dem BS leer geblieben - und 
der Test läuft jetzt deutlich schneller.

Der Speichertest hat in 8¼ Stunden 3 komplette Duchläufe ohne Fehler 
geschafft - schneller war das nicht, das schien nur so, weil die 
Fortschrittsanzeige des Memorytests grob unlinear ist.

Das Problem mit der VM ist hartnäckig. Das riecht nicht gut, denn die 
hat es jahrelang völlig problemlos getan…

Ich habe das Problem mit der VM im Oracle-Forum beschrieben und das 
VB-Log mit hochgeladen - mal sehen, was die herausfinden.

Das Problem war eher eines der banaleren Art: Die Hardware-Unterstützung 
der Virtualisierung im BIOS des Hostsystems war abgeschaltet. Das muss 
irgendwie durch die Bastelei passiert sein, denn die 
BIOS-Grundeinstellungen hatte ich überhaupt nicht geöffnet.

Nach der Reaktivierung lief die VM wieder. Oracle hat sehr fix reagiert.

Mal sehen, wie sich die Kiste jetzt weiter verhält und vielen Dank für 
die Hilfe.

Aber nochmal zum Eingangsposting zurück: ich finde die Idee noch immer 
interessant, den Include-Baum irgendwie interaktiv durchsuchen zu 
können.

Es ist natürlich nett, wenn die eine oder andere IDE sowas bietet, aber 
wie es der Teufel so will, benutzt man gerade nicht die, die es kann, 
wenn es braucht.

Die ökonomischere Lösung wäre ein Kommandozeilen-Tool wie z.B. grep - 
das könnten die IDEs dann einfach mit den entsprechenden Parametern 
aufrufen, statt das Rad neu zu erfinden…

In diesem Thread sieht man mal schön, wie der Weg von einem 
vermeintlichen Quelltextproblem zum Austausch eines Netzteils führen 
kann. Kann, weil der Fall doch ziemlich selten vorkommt, denn meistens 
hat man die Gurke ja selbst irgendwo eingebaut…

Mit "cpp -M" solltest du die Dependencies auflisten können, daraus 
sollte sich dann eine Liste der zu durchsuchenden Files aufbauen und an 
ein ganz gewöhnliches grep weiterreichen lassen.

Nur so als Bastelansatz.

Diese -M - Liste enthält nur die Abhängigkeiten Header-Files der 
Quelldatei. Das ist gedacht, um die Abhängigkeiten in einen Makefile 
einzubauen - bei dem von mir geschilderten Problem bringt das leider gar 
nichts.

Die Idee, so ein Werkzeug mal so eben nebenbei zu "basteln" siehe hier: 
Beitrag "Re: grep-ähnliches Werkzeug gesucht"

Je nach Aufgabenstellung eignet sich ‘grep’ sogar ganz gut. Andererseits 
kann man auch mit ‘Universal ctags’ und ‘GNU Global’ gute Ergebnisse 
erzielen. Wenn es wirklich genau sein soll, was z.B. in meinen 
Anwendungen meist gar nicht gewünscht ist, musst Du vielleicht mal im 
LLVM Umfeld nachsehen. Die haben ja eine Reihe von Werkzeugen zur 
Analyse.

Einige Sprachen mit denen ich zu tun habe, haben für sich betrachtet 
keine “include-Reihenfolge”. Was #ifdef (bzw dessen Pendant) angeht, 
möchte ich das meist ignorieren, so dass ich alle Stellen angezeigt 
bekomme, an denen z.B. eine Variable möglicherweise zugewiesen wird. 
Meist sind die Alternativen ja nicht so zahlreich.

Letztlich muss man sich darüber klar sein, dass Tools, die nicht direkt 
einer Compilersuite entstammen, Fehler im Parser haben, die zu false 
negatives führen können, also die eigentlich gesuchte Stelle nicht 
anzeigen. Scheinbar paradoxerweise sind hiervon die cleversten Werkzeuge 
betroffen, während ‘grep’ einfach nur viele false positives anzeigt. 
False positives sind aber meist nicht so schlimm, da man die im Kopf 
leicht wegfiltern kann.

Marcus H. schrieb:
> False positives sind aber meist nicht so schlimm, da man die im Kopf
> leicht wegfiltern kann.

Wenn du so willst, kannst du auch gleich den Code mit dem Hex-Editor in 
den Speicher klopfen…

Wenn du ein extrem verwirrendes Szenario hast, wie das, von dem ich 
ausging, dann suchst du nach Mitteln, die den ganzen Mist 
übersichtlicher machen und willst dich nicht auch noch mit "im Kopf 
leicht wegfiltern" auseinandersetzen…

Idealerweise hat man natürlich auch keine false positives. Sie sind aber 
meiner Erfahrung nach immernoch besser als beispielsweise genau die 
Zuweisung, die sich später als die Ursache eines Fehlers herausstellt, 
durch einen ungenauen Parser nicht angezeigt zu bekommen. Eigene 
Erfahrung. YMMV.