Tool zur Unterstützung der 32- auf 64-Bit-C++-Migration auf einer riesigen Codebasis

TL;DR : Ich brauche Tools, um problematischen Code in einer 32- auf 64-Bit-C++-Linux-Migration zu finden (Tools können unter Linux oder Widows laufen).

Hier ist es also, ich habe eine riesige C++-Anwendung (wir sprechen von mehr als 8 Millionen Codezeilen), die ich von einer 32-Bit-Plattform auf eine 64-Bit-Plattform (unter Linux) portieren möchte. Der Grund für die Portierung des Codes ist nicht fraglich, meine Aufgabe ist es, dies zu tun. Die App ist auf 32 Bit voll funktionsfähig, aber der Code kann teilweise sehr alt sein und ist eindeutig nicht mit den neuesten Standards und bewährten Verfahren codiert. Um erfolgreich zu sein, muss ich alle Codefragmente lokalisieren, die problematisch sind, wenn sie in 64-Bit kompiliert werden, ohne zu viele Fehlalarme zu entdecken, da wir über Millionen in Zeilen sprechen und ich nicht über die Ressourcen verfüge, um den gesamten Code umzugestalten, um ihn sauber und hübsch zu machen. Abschließend meine Frage, welche Tools können mir bei dieser Aufgabe helfen?

Ich habe PVS-Studio in Betracht gezogen, aber es scheint für Windows-Apps konzipiert zu sein. Ich habe auch überlegt, Compiler-Meldungen wie Gcc und Clang-Warnung zu verwenden, aber es gibt viel zu viele Fehlalarme, da es im 32-Bit-Fall bereits viele davon gibt. Ich habe auch statische Analysetools wie Cppchack, Klowork, Gimpel Pc-Lint und FlexeLint oder "Parasoft C++ test" in Betracht gezogen, aber ich kenne diese Tools nicht wirklich und ob sie mir wirklich helfen können.

Kurz gesagt, die Muster, die ich lokalisieren muss, sind (fragen Sie mich, wenn Sie mehr Details benötigen):
- problematische Verwendung von Typen mit unterschiedlicher Größe in 32 und 64 Bit
- durch die Migration verursachte Überläufe
- problematische magische Werte
- Änderung der Speicherausrichtung in der Struktur, Union und so
- schlechte Verwendung des Formatbezeichners (wie in printf(“%u”, val); wenn val ein Long ist) - problematische implizite Umwandlung
- Methoden und Funktionen, die nicht mehr übereinstimmen (virtuelle und überladene Methode)

Die 4 wichtigsten Punkte sind:
- Ich muss alle durch die Migration verursachten Probleme finden oder wissen, welche Arten von Problemen ich übersehen habe, wenn ich sie nicht finden kann.
- Ich brauche wenige Fehlalarme oder eine Möglichkeit, sie schnell zu eliminieren (Automatisierung erforderlich)
. - Die Lösung muss industriell sein (dh skriptfähig oder automatisch). Es ist eine riesige Codebasis, Handarbeit ist nicht möglich.
- Die Lösung kann ein Tool oder eine Reihe von Tools sein, kostenlos oder nicht, Linux oder Windows.

Es wäre ein Plus, wenn das Tool mit einer schönen und übersichtlichen Dokumentation geliefert wird.

Wenn Sie jemals ein solches Problem hatten, danke ich Ihnen für jeden Rat, den Sie mir geben können.

Sie müssen einzelne Benutzer der verschiedenen statischen Analysetools dazu bringen, Ihnen mitzuteilen, ob sie über eingebaute Regeln verfügen, um Ihre spezifischen Umstände zu erkennen. Einige könnten; Sie werden wahrscheinlich aus irgendeinem Grund seltsamen Code in Ihrem System haben, den solche Regeln nicht erkennen, und jetzt brauchen Sie Skriptfähigkeit. Ich glaube nicht, dass diese Tools sehr skriptfähig sind. Keiner von ihnen wird Ihnen helfen, den Code tatsächlich zu reparieren.
Im Moment muss ich den Code nicht reparieren, sondern nur die Probleme finden. Ich weiß, dass ich sie nicht alle finden werde, und das ist kein großes Problem. Deshalb haben wir ein seriöses Test- und Integrationsverfahren. Aber je mehr ich finde und je weniger Fehlalarme ich erhalte, desto besser. Ziel ist es, die Anzahl der Fixes einzugrenzen, um nicht von der Arbeit überschwemmt zu werden.

Antworten (1)

Ja, ich habe Aufgaben mit umfangreicher Analyse und Modifikation von Code, einschließlich C++, erledigt. Ich baue Tools, die explizit dafür ausgelegt sind.

Unser DMS Software Reengineering Toolkit mit seinem C++ Frontend könnte hilfreich sein.

(Da dies keine Standardlösung für das Problem des OP ist, kann ich hier keine Empfehlung aussprechen, sondern nur auf seine Existenz hinweisen. Ich werde behaupten, dass es sich um eine praktikable Lösung für sein Problem handelt, wie angegeben).

Was DMS bietet, ist die Möglichkeit, ein benutzerdefiniertes ("skriptbasiertes") Analysetool zu konfigurieren, das sich auf die spezifischen Anforderungen einer bestimmten Codebasis konzentriert. Sein C++-Parser kann C++14-Quellcode im GCC- oder MSVS-Stil lesen, vollständige ASTs, Compiler-genaue Symboltabellen und lokale Steuerungs- und Datenflussanalysen für Methoden/Funktionen erstellen. Es verfügt über eine integrierte Unterstützung zum Analysieren von Wertebereichen, die eine Variable sein kann. Mit diesen Grundlagen ist es oft praktisch, einen fokussierten Analysator zu bauen, der bestimmte interessierende Probleme erkennt.

In dem Maße, in dem ein Problem erkannt wird und eine bekannte Lösung hat (stellen Sie sich vor, Sie kopieren einen 32-Bit-Zeiger in ein 32-Bit-Int; auf einem 64-Bit-Computer muss das 32-Bit-Int auf 64 Bit umdeklariert werden), DMS kann Source anwenden -to-Source-Programmtransformationen , um die ASTs zu modifizieren und dann den Quellcode aus den modifizierten Bäumen neu zu generieren. Dies kann eine große Hilfe bei der Verwaltung der Änderungskosten nach der Erkennung sein. DMS wurde für andere Massenänderungsaufgaben verwendet, die auf C++-Quellcode angewendet wurden.

In Bezug auf benutzerdefinierte Analysatoren, die für die Aufgaben von OP benötigt werden:

  • Größenunterschiede bei Datentypen: DMS verfügt über vollständige Typinformationen für jede deklarierte Entität und berechnet Typen jeder Ebene jedes Ausdrucks, genau wie ein C++-Compiler. Sie können diese Informationen verwenden, um Abweichungen zwischen dem Typ eines Quellwerts (z. B. Zeiger [der jetzt 64 Bit groß sein muss]) und seinem Ziel (z. B. ein Struct-Slot mit deklarierter 32-Bit-Größe) zu erkennen.
  • Überläufe, die durch die Migration verursacht werden: Wenn man die Typen/Bereiche von Summanden kennt, kann man den Bereich der Summe abschätzen und ob das Ziel eine Durchführung einer Addition aufnehmen kann.
  • problematische magische Werte: Wenn Sie diese aufzählen können, sind sie leicht zu erkennen. Ich denke, das Problem sind hier nicht die Werte, sondern der Kontext, in dem sie zu finden sind. DMS verfügt über die Datenflüsse, um den Kontext zu finden, damit er überprüft werden kann.
  • Speicherausrichtung Änderung der Struktur, Union und so: DMS hat die Typinformationen. Wo der "neue" Typ anders als 32 Bit sein muss, können Sie die Ausrichtung der Zieltypen überprüfen (z. B. Struct-Slots usw.)
  • Schlechte Verwendung des Formatbezeichners (wie in printf("%u", val); wenn val ein langer Wert ist): Dies erfordert die Interpretation des Formatbezeichners und die Überprüfung der Argumente. DMS verfügt über die erforderlichen Typinformationen
  • problematische implizite Umwandlung: Auch hier benötigen Sie Typinformationen für die ursprünglichen Typen und prüfen, ob die implizite Umwandlung den Quellwert unangemessen dehnt/verkleinert
  • Methoden und Funktionen, die nicht mehr übereinstimmen (virtuelle und überladene Methode): DMS weiß (für die gültige 32-Bit-Version), was die richtigen Überladungsübereinstimmungen sind. Wenn sich die Größe von Operanden ändert, kann man relativ einfach prüfen, ob die Argumentgröße entsprechend deklariert ist (oder DMS einfach die Operandengröße ändern lassen).

Keines davon ist wahrscheinlich so einfach, wie ich vorgeschlagen habe. Alle zusammen sind wahrscheinlich immer noch viel weniger Arbeit als der Versuch, Probleme über 8M SLOC von Hand zu erkennen/zu patchen.

Ihre Eckdaten:

  • Alle Probleme finden: Sie können benutzerdefinierte Analysatoren für jedes spezifische Problem erstellen. Einige werden einfacher sein als andere.
  • Minimieren Sie Fehlalarme: Einige benutzerdefinierte Analysatoren sind hueristisch oder algorithmisch, je nach Aufwand und Schwierigkeit der Analyse. Willkommen bei der automatisierten Programmanalyse und dem Turing-Tarpit. Nehmen Sie die Hilfe an, die Sie bekommen können.
  • Industrie: DMS wurde für eine Vielzahl komplexer Aufgaben in einer Vielzahl von Sprachen, einschließlich C++, verwendet. Es ist auf verschiedene Weise skriptfähig; DMS wurde entwickelt, um große Mengen zu handhaben.
  • DMS ist ein „Tookit“; eine Sammlung von Werkzeugen und Bibliotheken. Es ist kommerziell. Es läuft nativ unter Windows; es wurde gründlich unter Linux/Wine getestet.
  • Dokumentation: DMS ist für die Verwendung durch Dritte konzipiert. Tausende Seiten Online-Dokumentation, Tutorial-Folien und wir bieten einen Schulungskurs an, wenn Sie es wünschen.

DMS kann unter Windows oder unter Linux unter Wine ausgeführt werden.

Tool zur Unterstützung der 32- auf 64-Bit-C++-Migration auf einer riesigen Codebasis
AntwortenHierDatenschutz-Bestimmungen1y, 0v