EMB98

EMBEDDED 98 • NOVEMBRE • 2025 27 CONTROLLO DEI BUG L’Inspector tool di Tasking è sviluppato dallo stes- so team di ingegneri che ha creato il compilatore, utilizzando gli stessi processi. Ciò garantisce una profonda comprensione della progettazione del compilatore e l’adesione a standard per misurare la maturità dei processi, come Aspice. L’imple- mentazione di un compilatore per il controllo dei bug rispecchia quella del compilatore associato, con un codice aggiuntivo, chiamato rilevatore, che emette messaggi diagnostici quando viene individuata la causa principale di un bug. Que- sti rilevatori non devono essere intrusivi e non devono alterare lo stato interno del compilatore, poiché ciò comprometterebbe l’affidabilità dello strumento. Per verificare la non intrusività, il compilatore per il controllo dei bug eredita le suite di test del compilatore. In condizioni di test, il compilatore per il controllo dei bug può generare un codice binario. Il codice binario generato dal compilato- re per il controllo dei bug deve essere identico a quello generato dal compilatore associato. Questo test assicura che la diagnostica implementata nel compilatore per il controllo dei bug non influisca sul suo stato interno. Per ogni rilevatore vengono sviluppati test aggiuntivi per verificare che i mes- saggi diagnostici vengano emessi quando neces- sario. Inoltre, l‘Inspector tool viene utilizzato per verificare se le librerie fornite con il compilatore sono affette da un bug del compilatore. SICUREZZA | SOFTWARE Per aiutare a comprendere la natura e l’impatto dei bug del compilatore, essi possono essere classificati in di- verse categorie: i bug di errata compilazione si verifi- cano quando il compilatore genera un codice errato da un input valido. Ciò può essere dovuto a ottimizzazioni errate, controlli di sicurezza inadeguati o analisi stati- che non corrette; i bug di crash causano l’arresto del compilatore durante il processo di compilazione; i bug silenziosi introducono nel codice compilato errori dif- ficili da rilevare perché non causano guasti immediati. Tra gli esempi vi sono i bug di concorrenza e le perdite di memoria; i bug che richiedono workaround sono bug che i programmatori possono aggirare utilizzando solu- zioni temporanee o workaround fino a quando tali bug non vengono ufficialmente risolti. Bug di compilazione silenziosi I bug di errata compilazione e i bug silenziosi sono causati da errori di generazione, ottimizzazione e col- legamento del codice e presentano un rischio elevato di causare il malfunzionamento del software compi- lato. Tra gli esempi vi sono bug di allocazione dei re- gistri, trasformazioni errate dei loop, ottimizzazioni intra-procedurali sbagliate ed eliminazione errata del codice morto. La sfida di questi bug è che spesso è impossibile iden- tificare tutti i costrutti software che potrebbero inne- scarli dalla sola descrizione del problema. Mentre gli standard di codifica e gli strumenti di analisi statica mirano a mantenere bassa la complessità del codice sorgente, la complessità aumenta significativamente a livello di linguaggio intermedio utilizzato internamen- te dai compilatori una volta applicate le ottimizzazioni. Inoltre, un bug in una specifica fase di ottimizzazione può avere la sua causa principale in una fase di analisi, come l’analisi degli alias, che viene utilizzata da altre fasi di ottimizzazione. Pertanto, anche per il compiler engineer che risolve il bug, può essere impossibile de- scrivere tutti i potenziali costrutti del codice sorgente che lo innescano. Questa complessità di fondo influisce negativamente sulla qualità dei risultati della maggior parte dei metodi per verificare se un software è affetto da un bug del compilatore. Metodi di verifica Nell’industria automotive vengono impiegati vari meto- di per rilevare sistematicamente se il software è affetto da bug noti del compilatore. Il primo passo consiste nel comprendere gli errori esaminando le loro descrizioni, che includono le versioni del compilatore interessate e gli specifici costrutti software o software pattern che in- nescano il bug. Questa valutazione aiuta a determinare se gli errori si applicano al proprio progetto.