Newsgroup: it.comp.programmare.win32
Titolo: Strip di eseguibili e simboli

ora mi hanno consigliato di usare strip su file eseguibili generati dal gcc,
questa pratica funziona, cioe' mi riduce l'eseguibile piu' della meta', pero
mi trovo difronte alcuni parametri di questo comando ...
uno strip all simbols che rimuove anche i simboli di rilocamento (non
capisco questo rilocamento che e' ???, cioe' melo immagino avendo
programmato in assembler ma non so' se e' veramente lo stesso concetto di
rilocazione in memoria che so dell'assembler, e visto che il programma senza
quei simboli va cmq in runtime, mi pare che non sia proprio quello ...)
uno strip debug simbols
ed uno strip unused simbols
ora facendo un po' di prove vedo che l'eseguibile a cui strippo tutto e' il
piu' compatto seguito da quello degli unused, e per ultimo il debug ...
ora mi chiedo sapete dirmi qualcosa in piu' su questi simboli, cosa sono a
cosa servono ... sono standard per tutti i compilatori ... o cosa ???
ciao e grazie
ps: se devo cambiare canale mi potreste indicare il piu' indicato ?


I simboli ed il loro uso dipendono dal formato degli eseguibili
(COFF nel caso degli attuali eseguibili per win32).
Rimuovendo le informazioni di debug non puoi piu usare GDB
per il debugging dell'eseguibile.
Di solito piu che  compilare con la generazione delle informazioni di
debug attivata e poi eseguire strip, conviene (una volta debuggato
per bene il programma) attivare le opzioni di ottimizzazione adatte
e disattivare la generazione delle informazioni di debug.
Se vuoi compattare ancora di piu gli eseguibili puoi usare UPX
(lo trovi su 
upx.sf.net
).
Se proprio vuoi usare strip rimuovendo tutto, limitati agli eseguibili
di programmi.
Non usarlo con le DLL, altrimenti in base a:
- la versione delle binutils;
- la versione di gcc;
- la versione di Windows usata a runtime;
potrebbero esserci dei problemi (DLL che non si caricano ecc. ecc.).
Se cerchi con google dovresti trovare una discussione di qualche tempo
fa riguardo a come e' possibile ottimizzare la DLL cygwin rimuovendo
tutti i simboli non necessari e pure la sezione di rilocazione
(in pratica rendendola "mappata fissa in memoria"), ma IMHO per
la maggior parte degli utilizzi e' piu semplice generare da subito
(dopo il debug) eseguibili senza informazioni non necessarie
ed ottimizzato in modo da ridurre lo spazio richiesto (ed al limite
se proprio si vuole risparmiare spazio su disco, usare pure UPX).
L. Micheletto

 potrebbero esserci dei problemi (DLL che non si caricano ecc. ecc.).
mi hanno detto che sulle dll basta rimuovere tutti i simboli tranne quelli
di rilocazione per essere sicuro che funzionino sempre, confermi ???
sto guardando upx ... ma upx cosa fa ??? comprime l'eseguibile o leva pezzi
di codice non utilizzati ???
ciao

 
www.wotsit.com
divertiti :-)

 pezzi di codice non utilizzati ???
comprime l'eseguibile. Non usarlo se non sai cosa comporta
-- 
  < 
http://www.reactos.com/
 >  Open source clone of Windows NT. Current
      Don't stand, REACT!      version 0.1.2. C, C++ and ASM developers
                               and beta testers are welcome!

 pure UPX). 
UPX peggiora di molto le performance, perchč disattiva il demand paging 
per l'eseguibile principale (che se č stato passato con UPX, in genere,  
č anche il modulo piů grande e contenente la maggior parte del codice e 
delle risorse). Non andrebbe consigliato cosě a cuor leggero


 delle risorse). Non andrebbe consigliato cosě a cuor leggero
cazzo dove le studio tutte ste cose ... mi stai parlando in cirillico ...
cosa e' il demand paging ??? (capisco che e' una richiesta di paginazione ma
non l'ho mai sentita ne vista ...)
che problemi comporta UPX oltre a quelli che ho gia' capito dasolo leggendo
il suo help, che non puo' essere usato con eseguibili che usano se stessi
(il file intendo) come contenitori di dati, ma per il resto sono abbastanza
perplesso ...
ciao

 ha scritto nel messaggio
news:KN8Za.60360$cl3.1...@news2.tin.it...

grazie e' sempre un divertimento usare un motore di ricerca trovare 10000
mila pagine e poi dover scegliere i contenuti leggendole ...
se magari avevi qualcosa di piu' diretto era meglio che smazzarsi i
risultati di un motore di ricerca ...
cmq sto leggendo ...

 risultati di un motore di ricerca ...
Una volta nella pagina che ti ha indicato c'era un bel sito con
informazioni su tutti i formati.
Ora non so che è successo.
-- 
Marco Barisione
http://spazioinwind.libero.it/marcobari/

 ha scritto nel messaggio
news:bh3et2$e7s$1...@news.ngi.it...


 
AZZ!
Distrazione :-)

 Ora non so che è successo.
mi rimanda alla pagina di un motore di ricerca generico ... che pare una
brutta copia di google ... quindi non so che voleva farmi vedere ...
ho cercato un po' ma piu' che altro ho trovato informazioni di disassembling
e informazioni sui formati degli header ... senza trovare a cosa servano
tali info ...
ciao

 
http://www.wotsit.org/
questo e' giusto grazie ;-)
ciao

 di codice non utilizzati ???
Comprime l'eseguibile (risorse incluse) e gli piazza dentro uno stub
che scompatta al volo la parte compressa al momento del caricamento
in memoria.
L. Micheletto

 sezione di rilocazione, non solo i simboli).
uso il gcc 3.3.1 e le bin util 2.14 ma sinceramente non so minimamente fare
quello che hai detto ;-)
magari se riesci a spiegarmelo posso eseguire la stessa pratica anche sugli
exe che escono standard con tutti i simboli interni ...
infatti come dicevo in un'altro post scrivendo il classico "hello world"
usando il C++ e le classi della lib standard veniva generato un eseguibile
di 400 e piu' k, poi ho capito un po' come funzionava lo strip e lanciando
lo strip e rimuovendo tutti i simboli su tale eseguibile si ottiene che
scende sui 200k ... cmq sempre troppo grosso per i miei gusti per un
normalissimo hello world ...
con upx sul generato da 200k scendevo a 60k (ma non era piu' un'eseguibile
standard)
la cosa piu' divertente invece e' che facendo hello world in C con printf
ottengo un eseguibile compilato da 12k che strippato come sopra mi scende a
5k :-p (quindi spero sempre di riuscire a vedere un hello world C++ che al
massimo non superi il doppio dello stesso programma C)
ciao e grazie

 che problemi comporta UPX oltre a quelli che ho gia' capito dasolo
posso dirti che risparmia spazio su disco a discapito della memoria. Di 
piů non so


 boh? a scuola, ad esempio :-)
dai tu dove le hai imparate tutte ??? mi sento un topo in un labirinto ...
piu' studio e piu' c'e' da studiare ... e poi ci si perde in studi e non si
fa mai un cazz ...
ciao

brutta copia di google ... quindi non so che voleva farmi vedere ...
www.wotsit.org
sbirish.

 
www.wotsit.org
si ora melo son segnato e leggo piano piano ...
ciao e grazie a tutti ...

 massimo non superi il doppio dello stesso programma C)
Il C++ ti da piu cose del "semplice" C, ma chiede anche di piu.
Il problema piu che altro e' che con C++ quando usi certe feature
aumenti di tanto il volume della roba che alla fine viene linkata, senza
contare che ad esempio per quel che riguarda GCC, la parte "C puro" di
solito raggiunge una sufficiente robustezza e viene ottimizzata per bene
molto prima della parte "C++ con tutte le feature".
E' anche per questo che di solito se non si supera un certo livello
di complessita e' preferibile limitarsi al C puro.
L. Micheletto

 fittizie calcolate a partire da image base).
[cut]
ora,
1) il mio gcc genera eseguibile PE e non COFF ...
2) gli indirizzi cosi' mappati sono solo nella mia applicazione ??? cioe'
sono gli indirizzi all'interno del mio user space o all'interno della mia
singola istanza della apllicazione ??? (non penso che siano indirizzi
assoluti sulla macchina)
scusa ma come mai per gli eseguibili si puo' rimuovere la parte di
rilocazione senza danni ed invece per le dll si fanno danni ???
le dll non dovrebbero venire allocate all'interno della mia area di memoria
non sono tenute in cache in memoria dal SO cosi' che piu' applicazioni che
chiamano una dll ottengono sempre gli stessi indirizzi di funzioni senza
richiedere un ulteriore caricamento in memoria di tale dll che e' inutile
???, tanto le dll sono passive, cioe' hanno funzione che toccano aree di
memoria esterne a loro e non interne (a meno di statici in dll ma penso che
quasi mai si usano ...) ...
sto sbagliando ???
altra curiosita' se e' vero quello che affermo e' anche per questo che si
cerca di tenere i driver certificati per le periferiche, perche' le dll di
driver hanno lo spazio eseguibile in kernel space e se sono programmate
maliziosamente possono leggere e scrivere in tutto il range di indirizzi
della macchina senza incontrare problemi, giusto ???
ora mi chiedo ... le dll dei driver sono in kernel space, invece le dll che
carico io localmente sono nella mia user space, se abbiamo piu' utenti che
usano lo stesso sitema e chiamano la stessa dll locale, cosa succede ???
c'e' una zona super user in cui vengono mantenute le dll caricate cosi' da
non doverle ricaricare in ogni user space (ma cosi' non sarebbe poco sicuro
??) o per ogni user le dll vengono ricaricate nella loro area di memoria
cosi' che non possano uscirci illegalmente ???
che cosa e' hooking di dll ??? che pratica e' e come si fa' ???
ciao
ps. scusa se oltre alle domande base sono partito in 4 con tutto quello che
mi passava per la mente ... ma per ora leggendo giringiro non ho ancora
risposto a tali domande ...

 che cosa e' hooking di dll ??? che pratica e' e come si fa' ???
Vedi la documentazione di LoadLibrary, GetProcAddress
e SetWindowsHookEx.
L. Micheletto

 cosi' da non doverle ricaricare in ogni user space
sì. In memoria kernel ci sono delle liste di tutte le pagine di memoria 
caricate da tutti i processi, e flag che indicano se son state caricate 
da file di swap, da file o se non sono state caricate ma solo prenotate 
per uso futuro. Dopodichè, ogni volta che la CPU si lamenta di non aver 
trovato una pagina di memoria, il sistema risponde cercandola nella sua 
lista e caricandola nella CPU. Quando la CPU non ha più spazio, infine, 
il sistema è costretto a salvarsi nel file di swap le pagine di memoria 
meno importanti e rimuoverle dalla CPU (o a rimuoverle e basta, se sono 
state mappate da un file). Ad ogni switch di processo il sistema toglie 
tutte le pagine del vecchio processo, *tranne* quelle che condivide con 
il nuovo processo (ad esempio, le DLL caricate da entrambi, ma anche lo 
spazio di memoria del kernel - che è condiviso da *tutti* i processi, e 
quindi non necessita mai di essere switchato)
