Dovremmo compilare e spedire le librerie con informazioni di debug quando possibile?

Question

Dovremmo compilare e spedire le librerie con informazioni di debug quando possibile?

#1 da (4 voti)
#2 da (2 voti)
#3 da (1 voti)

3

C'è un costo considerevole (e doloroso) per gli sviluppatori che eseguono il debug di librerie esterne a causa del fatto che molte librerie sono distribuite in due edizioni: una con informazioni di debug, altre senza. Lo sviluppatore deve cercare e scaricare i file di debug e indirizzare l'ambiente di debug alla loro posizione. Questo è spesso un compito doloroso e soggetto a errori. C'è anche un sacco di lavoro relativo alla costruzione e alla distribuzione di quelle librerie.

Allo stesso tempo, il mondo è cambiato in modi che rendono obsoleta la versione "release" (cioè la versione senza informazioni di debug). Ad esempio:

Un runtime moderno può eliminare in modo efficiente le informazioni di debug, ottimizzare al volo ed eseguire il programma alla massima velocità. Esempi sono gli interpreti JVM e JavaScript.
I progetti open source oi file binari non pubblicati all'esterno dell'azienda non hanno motivo di essere offuscati. Inoltre, dato che molti linguaggi moderni ora supportano la riflessione, l'offuscamento mediante la rimozione delle informazioni di debug è molto limitato, se del tutto efficace.
Lo spazio su disco è elevato, le prestazioni del disco (SDD) stanno migliorando e anche la larghezza di banda della rete sta migliorando.

Tieni presente che questa domanda è limitata alle librerie . Sono al 100% OK sulla distribuzione di applicazioni senza eseguire il debug delle informazioni, che è in realtà estremamente importante nel mondo mobile.

Dopo un sacco di problemi con PDB .NET e file .class senza informazioni di debug, penso che dovremmo evolvere processi e strumenti in un mondo in cui predefinito è per compilare e distribuire librerie con informazioni di debug, incorporate nel file binario (come i file .class), se possibile. Dopo tutto, l'unica ragione remota per non farlo è proteggere i diritti d'autore (che non si applica a molti scenari).

Naturalmente, gli strumenti che comprimono applicazioni dovrebbero essere abbastanza intelligenti da cercare e distruggere ogni pezzo di informazioni di debug incorporato prima di essere pubblicate per il download. Questo si basa sul fatto che gli utenti finali eseguono raramente il debug delle applicazioni.

debugging productivity release copyright compiler

posta fernacolo 09.02.2017 - 23:46

fonte

3 risposte

Leggi altre domande sui tag debugging productivity release copyright compiler

In che modo i loop di rete "catturano" effettivamente le connessioni? Qual è il vantaggio della copertura dell'istruzione (codice byte) sulla copertura di linee e diramazioni?

score 4 · Answer 1

Potrebbe anche essere una domanda per i tuoi avvocati.

Una libreria (o un eseguibile) compilata con informazioni di debug (ad esempio in C ++, su Linux, compilata con g++ -g2 -O2 in ELF formato con DWARF informazioni di debug) contiene molti dati [meta-] che facilitano reverse engineering del tuo codice.

Se rilasci quella cosa a clienti esterni, esponi loro alcune delle loro proprietà industriali / intellettuali (in particolare tutte le strutture dei dati, la gerarchia delle classi, il nome dei tuoi file, classi, funzioni, variabili, ecc. .). La decompilazione del tuo codice diventa molto meno difficile (anche se rimane piuttosto difficile).

Inoltre, le informazioni di debug richiedono molto spazio. Ciò potrebbe comportare dei costi (larghezza di banda, volume di dati) durante la distribuzione del software.

^{BTW, producendo software open source facilita ancora di più il tuo lavoro, con il potenziale beneficio che alcuni il collaboratore esterno potrebbe leggermente migliorarlo.}

Se puoi (cioè vuoi e ti è permesso) rilasciare le informazioni di debug, in effetti è più semplice rilasciare qualche binario (della tua libreria o del tuo programma) con le informazioni di debug incluse in esso (e non in un file separato ). Nota che molti compilatori sono in grado di ottimizzare ed emettere ancora informazioni di debug (ad esempio con GCC puoi compilare con entrambi -g -O2 flags; il debug le informazioni sono lì, ma sono "approssimative" a causa delle ottimizzazioni).

score 2 · Answer 2

L'idea qui proposta è che la spedizione delle informazioni di debug con una libreria software facilita lo sviluppo di applicazioni per tale libreria. Se questo è vero, implica che i programmatori abbiano bisogno di una conoscenza approfondita di come funziona il codice della libreria per far funzionare il proprio codice. Questo è ciò che è noto come cattivo odore. Se è vero che la conoscenza aiuta i programmatori, la biblioteca e in particolare le funzioni di confine non sono ben pensate o pulite. Fornire informazioni di debug in questo caso è una copertura contro la scarsa ingegneria e la scarsa documentazione.

Sai che sei nei guai quando è stato compilato tutto il codice che i team di ingegneri devono compilare per "Debug". Ho visto la mia parte del codice di livello di produzione rilasciato che è compilato per il debug perché i programmatori non possono risolvere problemi nella versione rilasciata del codice senza di esso. Non possono eseguire il debug senza un debugger e il codice non è stato creato per essere sottoposto a debug in altro modo. Quindi il codice rilasciato diventa sempre codice di debug. Sono stato catturato molte volte in questo ciclo come manager di ingegneria.

Ho incontrato librerie con eccezioni interne non rilevate; un altro cattivo odore. Ciò è causato dalla mancanza di parametri di controllo e integrità dei dati al limite dell'API. Sai quando c'è un'eccezione usata per molte situazioni di errore diverse che dicono qualcosa di inutile come "cose brutte sono accadute", quindi hai a che fare con un codice sporco. Tieni il tuo codice a uno standard più elevato in modo che i limiti si occupino degli errori interni e protegga la libreria dal codice di chiamata scadente. Forse c'è una sorta di registrazione che può essere utilizzata per aiutare a diagnosticare errori di runtime anche in produzione.

Un altro motivo per non fornire informazioni di debug è il codice che chiama la libreria potrebbe fare supposizioni sul funzionamento interno della libreria stessa che viola le informazioni nascoste. Questo è un problema aziendale perché diventa difficile apportare modifiche alla libreria nelle versioni future senza infrangere il codice di altre persone. Più presupposti sono fatti chiamando il codice, più è difficile e più costoso fornire nuove versioni della libreria.

L'arte della programmazione ha fatto molta strada ei programmatori sono ordini di grandezza più efficienti in questi giorni a produrre codice di qualità. In particolare, le potenti funzionalità di debug di IDE come Visual Studio ed Eclipse rendono molto più facile pompare grandi volumi di codice di alta qualità. Tuttavia, c'è un prezzo da pagare. A causa di questi strumenti, i programmatori hanno integrato pochissimo la diagnostica di runtime che può essere utilizzata per trovare un problema nel codice di produzione. Molti programmatori non imparano mai le abilità per correggere i bug a meno che non possano riprodurli in un debugger. Questo crea grossi problemi quando un bug emerge nel codice di produzione e tutti i clienti stanno urlando, ma lo staff di programmazione non può riprodurlo.

Nulla sostituisce il codice pulito e una grande API di auto-documentazione. Lasciando che i programmatori forniscano il codice di debug, invece, è un abbandono.

score 1 · Answer 3

No, non dovremmo. Le persone che includono condizionalmente codice eseguito in build di debug si aspettano che il codice venga eseguito solo nelle build di debug e mai nelle build di rilascio. Questo codice può essere solo il controllo invariante che è molto lento. O potrebbe essere un codice che potrebbe esporre vulnerabilità di sicurezza. Indipendentemente da ciò, devi supporre che ci sia una ragione per cui il codice era destinato solo per le build di debug.

La vera soluzione è creare librerie abbastanza robuste da non aver bisogno delle informazioni di debug. Ciò significa migliore design della libreria, migliore gestione degli errori, test automatici più inclusivi, ecc.

Se anche l'utente di una libreria deve eseguire il debug di quella libreria, sta perdendo tempo. La libreria potrebbe essere incredibilmente complessa internamente. Potrebbe essere necessario molto tempo per eseguire il debug del problema. E la "soluzione" determinata potrebbe essere completamente errata, a causa della mancanza di una comprensione completa.