Strumento di analisi statica per rilevare le interruzioni ABI in C ++

Non è molto difficile spezzare la compatibilità binario all’indietro di una libreria DSO / condivisa con un’interfaccia C ++. Detto questo, esiste uno strumento di analisi statica, che può aiutare a rilevare tali interruzioni ABI, se vengono forniti due diversi set di file di intestazione: quelli di uno stato precedente del DSO e quelli dello stato corrente (e forse anche i DSO)? Sono graditi sia suggerimenti di prodotti gratuiti che commerciali.

Se potesse anche mettere in guardia su cattive pratiche, ad esempio funzioni inline e parametri di funzione predefiniti nelle interfacce DSO, sarebbe fantastico.

Presumo che tu abbia familiarità con questo tutorial: Problemi di compatibilità binaria con C ++ , se non leggerlo!

Ho sentito parlare di questo strumento: http://ispras.linuxbase.org/index.php/ABI_compliance_checker , tuttavia mai testato o utilizzato, quindi non ho opinioni.

Potrebbe interessarti anche questo: creare una libreria con ABI compatibile con le versioni precedenti che usi Boost

abi-compliance-checker – uno strumento per il controllo della compatibilità backward binario / sorgente di una libreria C / C ++ condivisa (DSO):

Uno strumento per il controllo della compatibilità a livello di codice binario e sorgente di una libreria C / C ++. Lo strumento controlla i file di intestazione e le librerie condivise di vecchie e nuove versioni e analizza le modifiche in API e ABI (ABI = API + compilatore ABI) che possono compromettere la compatibilità binaria e / o di origine: modifiche nello stack chiamante, modifiche alla tabella v, simboli rimossi , campi rinominati, ecc.

inserisci la descrizione dell'immagine qui

icheck – Controllore ABI / API dell’interfaccia C:

Uno strumento per il controllo statico delle interfacce C per le modifiche API e ABI. Tutte le modifiche alle dichiarazioni di tipo che possono causare modifiche ABI dovrebbero essere rilevate, insieme alla maggior parte delle modifiche API. icheck è inteso per l’uso con le librerie, come metodo per prevenire la deriva dell’ABI.

shlib-compat – correttore di compatibilità ABI per librerie condivise con versioning di simboli:

shlib-compat usa i simboli di debug dei nani per ricreare e confrontare le definizioni dei simboli esportati, inclusi gli argomenti delle funzioni e i tipi strutturali.

Potresti anche essere interessato ai servizi di local tracker e linux abi tracker di Linux . Sono entrambi alimentati dallo strumento di controllo della conformità.

Ricordo che al lavoro usavano GCC XML per testare la compatibilità binaria. Fondamentalmente ciò che fa è generare una rappresentazione xml dell’albero degli oggetti del compilatore. La teoria dice che se l’xml è equivalente, è stata mantenuta la compatibilità binaria.

L’unico modo sicuro per fare ciò è esportare la tua libreria usando un’interfaccia C. Una libreria C ++ è compatibile solo con il compilatore che usi per compilarlo.

Il nostro strumento C ++ Smart Differencer confronta due file sorgente e riporta le differenze in termini di strutture linguistiche (identificatori, espressioni, dichiarazioni, …) e azioni di modifica plausibili (inserire, eliminare, spostare, copiare, sostituire-identificatore, …).

Non risponde direttamente alla domanda ABI, ma le informazioni fornite potrebbero essere piuttosto utili. Un esempio discusso in un’altra risposta è il tipo change-of-return da struct {a, b} a struct {b, a} . SmartDifferencer segnalerebbe che uno è stato spostato. (Nota: uno strumento diff regolare segnalerebbe che la riga contenente la struct definition è stata cambiata, quindi è ansible ottenere le stesse informazioni, ma SmartDifference ignorerà le modifiche in spazi bianchi / layout e commenti, producendo meno rumore concettuale).

Quello che nessuno di questi strumenti segnalerà è il cambiamento della definizione di typedef, è in un altro file di intestazione. Ma presumibilmente, si potrebbero confrontare tutti i file di intestazione coinvolti. Se non vuoi farlo manualmente, qualunque strumento sia in uso deve includere essenzialmente un parser C ++ completo, name resolver e deve confrontare le dichiarazioni per l’equivalenza. Un altro poster ha suggerito praticamente questa risposta: confrontare l’output GCCXML per l’equivalenza. Non sono sicuro di quanto sia facile nella pratica; non può essere solo “i file sono lo stesso XML in ordine?”.

ABI – Application Binary Interface si riduce al modo in cui il compilatore traduce il codice sorgente nelle istruzioni riconoscibili della macchina. la stessa linea di origine può essere tradotta in diversi flussi di byte, nel programma finale.

un analizzatore statico in esecuzione sul codice sorgente non sarà in grado di prevedere come il compilatore lo tradurrà. tale decisione viene presa nella codifica o nelle impostazioni del compilatore. quindi non credo che un analizzatore statico ti sarà d’aiuto in questo caso.