2011-06-15 28 views
25

Sono tentato di includere informazioni di debug nelle versioni di rilascio che escono ai clienti. Per quanto vedo l'unico lato negativo è il 25% di aumento della dimensione del file binario. Il vantaggio è che posso ottenere un crash dump immediatamente utilizzabile, molto più facile da analizzare. Sono disposto a vivere con un aumento del 25%. Ci sono altri svantaggi che mi mancano?Visual Studio: informazioni di debug nella versione di rilascio

Questo è un progetto C e tutto quello che voglio fare è legata/Debug/Genera informazioni di debug

risposta

35

La dimensione dell'eseguibile dovrebbe aumentare molto meno del 25%.

Sono un po 'sorpreso che aumenti di molto, ma alcuni test rapidi mostrano che almeno un grande progetto di esempio (ScummVM) aumenta l'exe da 10.205.184 byte a 10.996.224 byte semplicemente aggiungendo l'opzione /DEBUG a la fase di collegamento (circa un aumento dell'8%). /DEBUG viene specificato utilizzando l'opzione "Linker | Debugging | Generate Debug Info" nell'IDE. Si noti che queste impostazioni dovrebbero non hanno alcun effetto sulle ottimizzazioni generate dal compilatore.

So che un puntatore al file .pdb viene inserito nell'eseguibile, ma non c'è molto da fare. Ho sperimentato un po 'e ho scoperto che abilitare l'opzione linker /OPT:NOREF cambiava la differenza di dimensioni a 10.205.184 vs 10.205.696. Quindi il build non /DEBUG ha mantenuto le stesse dimensioni, ma il build /DEBUG è sceso a solo 512 byte più grandi (il che potrebbe essere spiegato dal puntatore-a-pdb - forse il linker arrotonda a qualche multiplo di 512 o qualcosa del genere). Molto meno dell'1% in più. Apparentemente, aggiungendo /DEBUG il linker manterrà oggetti senza riferimento a meno che non si specifichi anche /OPT:NOREF. (Opzione "Linker | Optimization | References" nell'IDE).

Il programma funzionerà correttamente senza il file .pdb - è possibile scegliere di inviarlo ai clienti se si desidera fornire una migliore esperienza di debug sul sito del cliente. Se vuoi solo essere in grado di ottenere tracce di stack decenti, non hai bisogno di avere il file .pdb sul computer del cliente - loro (o qualche strumento/funzionalità che fornisci) possono inviare un file di dump che può essere caricato in un debugger sul tuo sito con il file .pdb disponibile e ottieni le stesse informazioni di traccia stack port-mortem.

Una cosa, ovviamente, è che è necessario archiviare i file .pdb insieme alle proprie versioni. Il pacchetto "Debugging Tools per Windows" (che ora è distribuito in Windows SDK) fornisce uno strumento server dei simboli in modo da poter archiviare .pdbs e recuperarli facilmente per il debug.

L'unico inconveniente che posso pensare alla distribuzione di file .pdb è che può semplificare il reverse engineering dell'applicazione, se è una preoccupazione per voi.Si noti che Microsoft distribuisce i simboli per Windows (utilizzando un server di simboli pubblici) nonché i pacchetti dei set di simboli completi per alcune versioni specifiche. Tuttavia, i simboli che distribuiscono vengono sottoposti a un passaggio di disinfezione che rimuove alcuni elementi che considerano sensibili. Puoi fare lo stesso (o simile) usando l'opzione /PDBSTRIPPED del linker ("Linker | Debugging | Strip Private Symbols" nell'IDE). Vedi the MSDN docs per i dettagli su ciò che l'opzione rimuove. Se stai per distribuire i simboli, è probabilmente appropriato utilizzare questa opzione.

+0

Apparentemente, SCUMVM ha pochissimo codice non referenziato :) Dopo aver abilitato lo stripping dei simboli senza riferimento, la dimensione dell'eseguibile è tornata normale. Grazie mille! –

+0

Grazie per aver segnalato il riferimento del linker – Gob00st

-7

ho sempre inviare la build di debug, mai il build di rilascio. Non riesco a pensare ad alcun svantaggio, e i vantaggi sono quelli che menzioni.

+4

ottimizzazioni sono cose utili – SLaks

+2

@SLAks sì, sono d'accordo. Non sto facendo una build di debug, ma una build di rilascio con informazioni di debug ... la mia comprensione è che ha ancora tutte le ottimizzazioni, inclusi solo alcuni simboli di debug. Bene, questo è quello che sto cercando di chiarire con questa domanda. –

+0

Immagina un rivenditore di auto che dice "Vendo sempre prototipi di laboratorio, non la vera macchina della fabbrica" ​​... Oh, e probabilmente non ti è permesso distribuire il runtime di debug ai clienti (IANAL, ma dai un'occhiata alla licenza per il tuo compilatore). – Tibo

1

Non si parla in che lingua ci si trova, potrebbero esserci risposte diverse per C++ vs. C#.

Non sono sicuro al 100% quale sia il cambiamento che stai pensando di fare. Vuoi dire a Visual Studio di compilare il debug standard e spedirlo, o modifichi un paio di impostazioni nella compilazione di Release? Un'attenta modifica di un paio di impostazioni nella build Release mi sembra l'approccio migliore.

Qualsiasi cosa si verifichi, farei in modo che le ottimizzazioni siano attivate, in quanto ciò può fare una differenza significativa nelle prestazioni del codice compilato.

+0

Ho aggiornato la domanda con i chiarimenti richiesti. –

+0

Ma le altre domande sono ... come faccio ad assicurarmi che le ottimizzazioni siano ancora attive? Voglio dire, sono abilitati, ma cosa succede se "genera informazioni di debug" sovrascrive le impostazioni e le disabilita? –

+0

Se ci si trova in C piatta, questa impostazione si trova nelle pagine delle proprietà del progetto, in Proprietà di configurazione :: C/C++ :: Ottimizzazione. Credo che i valori predefiniti siano Optimization Disabled (/ Od) per i build di debug e Maximize Speed ​​(/ O2) per i build di Release. –

2

Secondo la documentazione VS2005 a http://msdn.microsoft.com/en-us/library/xe4t6fc1(v=vs.80).aspx:

/DEBUG cambia le impostazioni predefinite per l'opzione/OPT da REF per NOREF e da ICF a NOICF (quindi, è necessario specificare esplicitamente/OPT: REF o /OPT: ICF).

ho il mio caso mi ha aiutato quando ho attivato sia:

/O2 /DEBUG /OPT:REF /OPT:ICF 
Problemi correlati