# Autotools

## skypjack

Salve, vi propongo un quesito sugli autotools.

In pratica, ho sviluppato un piccolo software in C che, per vari motivi, volevo trattare con i tool di cui sopra per renderlo maneggevole, portabile e quant'altro. In fase di sviluppo, essendo sviluppatore unico, testavo sulla mia macchina passo dopo passo.

Attualemente, il codice funziona, se compilo con gcc senza alcun parametro di ottimizzazione, cioè giusto per fare dei test. Una volta però realizzato il contorno tramite l'uso dei tool sopra citati, ottengo (al termine di un ./configure && make all) un eseguibile di dimensione doppia rispetto al caso precedente e che "pianta" letteralmente la macchina, esaurendo (credo) la memoria e costringendo a continui swap su disco (vado un pò a intuito, perchè noto che il disco va sotto sforzo e niente funziona più fino a quando un bel CTRL-C mi viene in aiuto, dopo di che tutto torna alla normalità).

Ora, non nego che sono un novellino di tali tool e quindi ho tanto da imparare (ma proprio tanto), però questa cosa è alquanto strana e non riesco a spiegarmela, ma forse c'è una motivazione che ignoro e qualcuno potrà indicarmela... Almeno spero!!!!

Resto in attesa di una voce amica...

Ciao

----------

## randomaze

 *skypjack wrote:*   

> ma forse c'è una motivazione che ignoro e qualcuno potrà indicarmela... Almeno spero!!!!

 

Beh intanto puoi controllare cosa mette nel Makefile e in cosa tale file è diverso dal tuo....  :Rolling Eyes: 

----------

## skypjack

Ti dirÃ², ieri andavo un pÃ² di fretta e mi ero giÃ  appuntato di fare quanto mi hai detto, il fatto Ã¨ che l'unica variante significativa mi pare proprio la presenza di -O2, per questo ho sottolineato anche nella spiegazione che non usavo ottimizzazione ne quant'altro, ma proprio un semplice: gcc -o nome_prog *.c .

In ogni caso lo farÃ², ma altre indicazioni?

----------

## Scen

 *skypjack wrote:*   

> l'unica variante significativa mi pare proprio la presenza di -O2

 

Non è poco, -O2 introduce un bel pò di ottimizzazioni, e probabilmente il codicillo del tuo programma necessita di qualche correzione, se queste ottimizzazioni ne "sballano" il funzionamento.

Potresti configurare il tuo Makefile per far impostare in modo predefinito le ottimizzazioni ad un livello "basso" (-Os o -O1), e poi provare a sistemare il codice per renderlo funzionante con ottimizzazioni più spinte.

Comunque è normale che un binario compilato con ottimizzazioni varie abbia dimensioni più grosse di uno compilato "as-is"

Altri consigli non te ne so dare, non sono un esperto programmatore  :Confused: 

----------

## drizztbsd

 *Scen wrote:*   

>  *skypjack wrote:*   l'unica variante significativa mi pare proprio la presenza di -O2 
> 
> Non è poco, -O2 introduce un bel pò di ottimizzazioni, e probabilmente il codicillo del tuo programma necessita di qualche correzione, se queste ottimizzazioni ne "sballano" il funzionamento.
> 
> Potresti configurare il tuo Makefile per far impostare in modo predefinito le ottimizzazioni ad un livello "basso" (-Os o -O1), e poi provare a sistemare il codice per renderlo funzionante con ottimizzazioni più spinte.
> ...

 

-Os è peggio di -O2, non usatelo che spesso e volentieri rompe qualcosa.

Per debug prova con -O0 o -O1.

Solitamente la cosa che rompe di -O2 è -fstrict-aliasing, prova ad aggiungere -fno-strict-aliasing alle CFLAGS

----------

## randomaze

Da come descrivi il problema puoi usare top per vedere la memoria allocata dal tuo processo. E' un pò grezzo ma il tuo programma va a consumare tutta la memoria e poi la swap dovresti vederlo chiaramente.

Poi, quando sviluppi (e, perché no, quando rilasci non solo) sarebbe il caso di usare almeno -Wall per avere i warnings (i quali, anche se sono warnings e non error sarebbe bene che venissero risolti).

Già che ci sei controlla anche la fase di linking... con quali librerie e quali parametri vengono usati per l'eseguibile?

----------

## skypjack

Scusate, che cosa intendete dicendo che nel caso in cui -O2 da certi problemi bisogna rivedere il codice perchè potrebbe avere qualche problemuccio?

Così, giusto per capire di cosa devo andare alla ricerca...

Grazie per l'aiuto a tutti, intanto!!

----------

## Scen

 *skypjack wrote:*   

> Scusate, che cosa intendete dicendo che nel caso in cui -O2 da certi problemi bisogna rivedere il codice perchè potrebbe avere qualche problemuccio?

 

Alt, prendi le mie parole con le pinze, non sono un esperto programmatore, ma spero di non avere detto castronerie!  :Razz: 

Quello che penso è che un programma, se scritto bene, dovrebbe funzionare altrettanto egregiamente anche se vengono applicate delle ottimizzazioni di vario tipo al codice da parte del compilatore.

----------

## jordan83

 *Scen wrote:*   

> 
> 
> Quello che penso è che un programma, se scritto bene, dovrebbe funzionare altrettanto egregiamente anche se vengono applicate delle ottimizzazioni di vario tipo al codice da parte del compilatore.

 

Le ottimizzazioni non devono assolutamente andare a modificare il comportamento di un programma (ho fatto un corso all'università sull'argomento).

Il loro scopo è quello di rendere più efficiente l'esecuzione del codice (ad esempio rimuovendo variabili non utilizzate, estraendo dai cicli espressioni calcolate più volte, rimuovendo codice non raggiungibile, sostituendo il valore numerico alle costanti e molte altre tecniche).

Ne consegue che se il tuo programma esegue allegramente divisioni per 0, un'ottimizzazione non deve assolutamente modificare tale comportamento...   :Very Happy: 

Alcune ottimizzazioni tuttavia possono essere potenzialmente dannose, ad esempio perché valide solo in particolari "contesti", in presenza di particolari condizioni. Di conseguenza, se il compilatore sbaglia nel valutare il verificarsi di tali condizioni, l'eseguibile prodotto è potenzialmente instabile e la sua esecuzione probabilmente produce risultati diversi da quelli prodotti dallo stesso eseguibile non ottimizzato. Chiaramente questo deve essere considerato come un bug del compilatore, non un problema da ricondursi al programma.

Quindi, a meno che per gcc le regole in gioco non siano diverse (per qualche motivo a me ignoto), il codice del programma non deve essere "adeguato" alle ottimizzazioni  :Wink: 

----------

## skypjack

Quindi, visto che compilando senza parametri tutto funziona e valgrind non mi da problemi dopo svariati test, verso cosa dovrei orientarmi?

Il codice sembra funzionare correttamente, ho percorso quasi tutte le possibilità e non ha presentato errori, ma compilando con -O2 si "pianta" letteralmente... Che ne pensate??

Ora faccio alcune prove e vi so dare notizie per certo...

----------

## randomaze

 *skypjack wrote:*   

> Il codice sembra funzionare correttamente, ho percorso quasi tutte le possibilità e non ha presentato errori, ma compilando con -O2 si "pianta" letteralmente... Che ne pensate??

 

 *randomaze wrote:*   

> Poi, quando sviluppi (e, perché no, quando rilasci non solo) sarebbe il caso di usare almeno -Wall per avere i warnings (i quali, anche se sono warnings e non error sarebbe bene che venissero risolti).

 

----------

## skypjack

Ovvio, rand, intendevo se avete altre strade o idee da suggerirmi, così appena mi ci metto le controllo tutte.

Riformulo la domanda: Alla luce del fatto che su quanto già detto fin'ora ho preso appunti, avete altri suggerimenti?  :Wink: 

----------

## skypjack

Ok, ho fatto alcune prove di compilazione e proprio passando il parametro -O2 le prestazioni degradano come sopra detto.

Senza passare quel parametro, tutto funziona correttamente!!

Qualcuno saprebbe spiegarmi il perchè? Mi sembra assurdo... Sbaglio o dimentico qualcosa??

----------

## jordan83

 *skypjack wrote:*   

> Ok, ho fatto alcune prove di compilazione e proprio passando il parametro -O2 le prestazioni degradano come sopra detto.
> 
> Senza passare quel parametro, tutto funziona correttamente!!
> 
> Qualcuno saprebbe spiegarmi il perchè? Mi sembra assurdo... Sbaglio o dimentico qualcosa??

 

Mah, potresti provare a debuggare e vedere a che punto il programma inizia ad abbuffarsi di risorse.

Probabilmente qualche ottimizzazione non ha fatto bene il suo lavoro, non so. Personalmente non ho una grandissima esperienza.

In più è difficile dare risposte senza poter vedere il sorgente o sapere cosa fa sto programma.

Un'altra cosa che potresti fare è usare le ottimizzazioni raccolte in O2 singolarmente, in modo da capire quale sia quella che crea problemi.

Inoltre potresti ricontrollare il codice, soprattutto i cicli; magari uno di essi presenta un comportamento bizzarro sotto certe condizioni, anche se è molto improbabile visto che dici che tutto funziona senza O2...  :Neutral: 

Magari hai trovato un bug di gcc!  :Wink: 

----------

## skypjack

 *jordan83 wrote:*   

> 
> 
> Mah, potresti provare a debuggare e vedere a che punto il programma inizia ad abbuffarsi di risorse.
> 
> Probabilmente qualche ottimizzazione non ha fatto bene il suo lavoro, non so. Personalmente non ho una grandissima esperienza.
> ...

 

Vedi, per punti:

- ora sto facendo debug sotto -O2, poi vi dirò

- il codice al momento non posso distribuirlo per motivi che, se vuoi, ti spiego anche (ma è un pò lunga)

- come scovo le ottimizzazioni fatte in O2?

- bug di gcc? lo vedo molto ma molto probabile, sai, viste le mie indubbie capacità!!  :Wink: 

----------

## Guglie

 *skypjack wrote:*   

> - come scovo le ottimizzazioni fatte in O2?

 

http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gcc/Optimize-Options.html

----------

## skypjack

Ok, sono un idiota, perchè lo sapevo pure!! Sorry per la domanda inutile...  :Wink: 

[EDIT]:

Ho ristretto il campo ad una funzione, controllando che all'ingresso tutto sia corretto (e lo è) e valutando che all'uscita qualcosa è andato storto!!

Ristringere i dubbi ad un solo file .c non è poco, direi!!  :Very Happy: 

Il fatto è che questa funzione ha mille piccole funzioni di supporto!!!!!!!  :Sad: 

Quel file .c in particolare è un pò lungo, mi ci vorra un bel pò a scovare il bug...

Grazie dell'aiuto, per adesso, a tutti!!

----------

## skypjack

Salve a tutti, oltre che ringraziare ancora per l'aiuto, chiedo pubblicamente di essere crocifisso in sala mensa!!

Astutamente, mi era sfuggito un -Wall fra i parametri e, una volta notato e dato, ha messo in risalto due o tre pecchè che effettivamente compromettevano il corretto funzionamento del programma, una volta ottimizzato.

Mi è bastato risolvere i warning e tutto è tornato a funzionare, anche post-ottimizzazione!!

Grazie ancora e scusate l'inutile discussione causa sbadataggine!!

----------

## randomaze

 *skypjack wrote:*   

> Mi è bastato risolvere i warning e tutto è tornato a funzionare, anche post-ottimizzazione!!

 

Per curiosità, cosa dicevano i messaggi in questione?

----------

## skypjack

Ora, ovviamente, non so ripeterteli, perchè corretti.

In ogni caso, se non sbaglio, erano un valore di ritorno che non tornava, una %d al posto di un %f e una macro _GNU_SOURCE mancante, ma mi pare ci fosse un'altro punto.

Se mi viene altro in mente, te lo dico.

Perchè ti incuriosisce tanto?

----------

## randomaze

 *skypjack wrote:*   

> Perchè ti incuriosisce tanto?

 

Perché (sto ragionando alla cieca sulla base delle tue informazioni) il tuo problema era, presumibilmente, un ciclo che allocava la memoria e non terminava. Questo potrebbe essere dato da un cast errato su una variabile signed/unsigned o da un controllo su un puntatore che in realtà puntava a qualcos'altro.

Volevo vedere se ci avevo preso o meno... escludo il problema possa essere dipeso dalla stringa di formattazione (in quel caso alla peggio o stampa valori errati oppure lascia un core) ma probabilmente era il _GNU_SOURCE mancante (e qui bisognerebbe vedere quali ifdef/ifndef vengono eseguiti dalle librerie su quella macro per capire la discordanza dei dati a cosa era dovuta.

----------

## skypjack

Anch'io mi sono orientato sul _GNU_SOURCE mancante, come fonte del problema. In ogni caso, avendo risolto, non ho indagato ulteriormente.

Mi capirai, credo...

----------

