parzialmente OT: Dr. Memory (tool per sviluppatori)

[a.furieri]

visto che e' un tool abbastanza nuovo e non ancora troppo noto
credo di fare una cosa potenzialmente utile segnalandovi questo
pacchetto decisamente molto utile.

Dr. Memory http://www.drmemory.org/

recensione ultra-quick
----------------------
si tratta di un analizzatore dinamico di codice, ed e' piu' o meno
equivalente all'assai piu' noto Valgrind: http://valgrind.org/

la cosa *molto* interessante e' che Dr. Memory gira indifferentemente
sia su Windows (32 bit) sia su Linux e persino sotto Mac OsX, mentre
invece Valgrind gira esclusivamente su Linux.
finalmente abbiamo un tool completo ed abbastanza sofisticato anche
sulle piattaforme Windows.

detta in due parole, si tratta di strumenti sw che eseguono un
programma qualsiasi al proprio interno tenendo sotto costante
monitoraggio tutte le operazioni che interessano la memoria
dinamica di tipo heap, cioe' quella che in C si gestisce tramite
malloc/free ed in C++ tramite new/delete.
l'unico pre-requisito richiesto e' che il programma bersaglio
va compilato in modo un po' speciale, in modo tale da conservare
all'interno dell'eseguibile tutti i numeri di linea che consentono
di risalire al punto esatto del sorgente che causa il problema.

nel 99% dei casi i bugs veramente rognosi da identificare e
risolvere (quelli che accadono in modo apparentamente capriccioso
e magari difficile da riprodurre in modo deterministico) affondano
le proprie radici profonde proprio in quest'area critica.
ecco spiegato perche' un tool diagnostico di questo tipo e' un
vero e proprio toccasana che consente di arrivare a distribuire
codice molto robusto e stabile a prova di bomba.

le condizioni pericolose da tenere sempre sotto stretto controllo
rientrano nelle seguenti categorie:

- memory leaks: il programma alloca blocchi di memoria dinamica
   che poi si dimentica sbadatamente di liberare quando non servono
   piu'. la conseguenza negativa e' in questo modo pian piano la
   memoria si esaurisce, le performances peggiorano progressivamente
   ed infine si puo' anche arrivare ad un bel crash per esaurimento
   delle risorse.
   e' una condizione decisamente pericolosa per tutte le app con
   una GUI, ma e' ancor piu' nefasta per i processi server che
   restano ininterrottamente in esecuzione anche per mesi e mesi.

- buffer overflow: il programma alloca p.es. 1000 bytes, ma poi
   all'atto pratico cerca di leggerne o scriverne un po' di piu'
   (p.es. 1005) finendo cosi' per sfondare i limiti dell'allocazione.
   la cosa finisce assai spesso con qualche bel fuoco di artificio :-)

- memoria non inizializzata: il programma dimentica di assegnare
   esplicitamente un valore iniziale opportuno ai blocchi di memoria
   dinamica che alloca via via.
   dopo di che il primo tentativo di utilizzare comunque quei dati
   puo' facilmente causare effetti stravaganti e bizzarri.
   di fatto questo e' il meccanismo tipico che sta alla base di piu'
   o meno tutti i "bugs misteriosi", quelli che "accade solo una
   volta su mille", "accade solo sul PC di Giorgio, su tutti gli
   altri PC funziona sempre perfettamente" o magari "su Linux gira
   sempre bene, invece su Windows spesso va in crash ma a volte
   funziona normalmente, dipende da come gli gira".

usare regolarmente tools come Valgrind o Dr. Memory semplifica
notevolmente il compito di identificare e poi risolvere tutti
i pasticci e pasticcetti di questa natura.
ecco spiegato perche' questi strumenti dovrebbero sempre fare
parte integrante dei normali strumenti di sviluppo e verifica
della qualita' per qualsiasi progetto di sw libero "serio".

venendo piu' nello specifico a Dr. Memory:
* alla prova dei fatti funziona sorprendenemte bene
* l'installazione e' facilissima, cosi' come e' molto facile
   compilare il programma da sottoporre a monitoraggio: basta
   leggersi poche righe chiaramente documentate e praticamente
   parte tutto da solo in cinque minuti.
* su Win supporta indifferentemente sia MinGW che MSVC
* il progetto ha nobilissime ascendenze, visto che si basa su
   DynamoRIO, un toolkit sviluppato inizialmente da HP in
   stretta collaborazione con il prestigioso MIT
* last but not least, e' tutto free sw rilasciato sotto LGPL;
   e' decismanete interessante scoprire che per i primi anni
   ha mosso i propri passi come prodotto proprietario, ma piu'
   di recente e' diventato sw libero a tutti gli effetti.
   Evviva il figliol prodigo :-D

ciao Sandro

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015

[Luigi Pirelli-2]

+1
Luigi Pirelli

**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Elance: https://www.elance.com/s/edit/luigipirelli/
* GitHub: https://github.com/luipir
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* Mastering QGIS:
https://www.packtpub.com/application-development/mastering-qgis
**************************************************************************************************


2015-05-25 11:55 GMT+02:00  <[hidden email]>:

> visto che e' un tool abbastanza nuovo e non ancora troppo noto
> credo di fare una cosa potenzialmente utile segnalandovi questo
> pacchetto decisamente molto utile.
>
> Dr. Memory http://www.drmemory.org/
>
> recensione ultra-quick
> ----------------------
> si tratta di un analizzatore dinamico di codice, ed e' piu' o meno
> equivalente all'assai piu' noto Valgrind: http://valgrind.org/
>
> la cosa *molto* interessante e' che Dr. Memory gira indifferentemente
> sia su Windows (32 bit) sia su Linux e persino sotto Mac OsX, mentre
> invece Valgrind gira esclusivamente su Linux.
> finalmente abbiamo un tool completo ed abbastanza sofisticato anche
> sulle piattaforme Windows.
>
> detta in due parole, si tratta di strumenti sw che eseguono un
> programma qualsiasi al proprio interno tenendo sotto costante
> monitoraggio tutte le operazioni che interessano la memoria
> dinamica di tipo heap, cioe' quella che in C si gestisce tramite
> malloc/free ed in C++ tramite new/delete.
> l'unico pre-requisito richiesto e' che il programma bersaglio
> va compilato in modo un po' speciale, in modo tale da conservare
> all'interno dell'eseguibile tutti i numeri di linea che consentono
> di risalire al punto esatto del sorgente che causa il problema.
>
> nel 99% dei casi i bugs veramente rognosi da identificare e
> risolvere (quelli che accadono in modo apparentamente capriccioso
> e magari difficile da riprodurre in modo deterministico) affondano
> le proprie radici profonde proprio in quest'area critica.
> ecco spiegato perche' un tool diagnostico di questo tipo e' un
> vero e proprio toccasana che consente di arrivare a distribuire
> codice molto robusto e stabile a prova di bomba.
>
> le condizioni pericolose da tenere sempre sotto stretto controllo
> rientrano nelle seguenti categorie:
>
> - memory leaks: il programma alloca blocchi di memoria dinamica
>   che poi si dimentica sbadatamente di liberare quando non servono
>   piu'. la conseguenza negativa e' in questo modo pian piano la
>   memoria si esaurisce, le performances peggiorano progressivamente
>   ed infine si puo' anche arrivare ad un bel crash per esaurimento
>   delle risorse.
>   e' una condizione decisamente pericolosa per tutte le app con
>   una GUI, ma e' ancor piu' nefasta per i processi server che
>   restano ininterrottamente in esecuzione anche per mesi e mesi.
>
> - buffer overflow: il programma alloca p.es. 1000 bytes, ma poi
>   all'atto pratico cerca di leggerne o scriverne un po' di piu'
>   (p.es. 1005) finendo cosi' per sfondare i limiti dell'allocazione.
>   la cosa finisce assai spesso con qualche bel fuoco di artificio :-)
>
> - memoria non inizializzata: il programma dimentica di assegnare
>   esplicitamente un valore iniziale opportuno ai blocchi di memoria
>   dinamica che alloca via via.
>   dopo di che il primo tentativo di utilizzare comunque quei dati
>   puo' facilmente causare effetti stravaganti e bizzarri.
>   di fatto questo e' il meccanismo tipico che sta alla base di piu'
>   o meno tutti i "bugs misteriosi", quelli che "accade solo una
>   volta su mille", "accade solo sul PC di Giorgio, su tutti gli
>   altri PC funziona sempre perfettamente" o magari "su Linux gira
>   sempre bene, invece su Windows spesso va in crash ma a volte
>   funziona normalmente, dipende da come gli gira".
>
> usare regolarmente tools come Valgrind o Dr. Memory semplifica
> notevolmente il compito di identificare e poi risolvere tutti
> i pasticci e pasticcetti di questa natura.
> ecco spiegato perche' questi strumenti dovrebbero sempre fare
> parte integrante dei normali strumenti di sviluppo e verifica
> della qualita' per qualsiasi progetto di sw libero "serio".
>
> venendo piu' nello specifico a Dr. Memory:
> * alla prova dei fatti funziona sorprendenemte bene
> * l'installazione e' facilissima, cosi' come e' molto facile
>   compilare il programma da sottoporre a monitoraggio: basta
>   leggersi poche righe chiaramente documentate e praticamente
>   parte tutto da solo in cinque minuti.
> * su Win supporta indifferentemente sia MinGW che MSVC
> * il progetto ha nobilissime ascendenze, visto che si basa su
>   DynamoRIO, un toolkit sviluppato inizialmente da HP in
>   stretta collaborazione con il prestigioso MIT
> * last but not least, e' tutto free sw rilasciato sotto LGPL;
>   e' decismanete interessante scoprire che per i primi anni
>   ha mosso i propri passi come prodotto proprietario, ma piu'
>   di recente e' diventato sw libero a tutti gli effetti.
>   Evviva il figliol prodigo :-D
>
> ciao Sandro
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni
> dell'Associazione GFOSS.it.
> 750 iscritti al 18.3.2015

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015

[donpetros]

grazie mille è molto utile

ciao

Il giorno 25 maggio 2015 11:55, <[hidden email]> ha scritto:

visto che e' un tool abbastanza nuovo e non ancora troppo noto
credo di fare una cosa potenzialmente utile segnalandovi questo
pacchetto decisamente molto utile.

Dr. Memory http://www.drmemory.org/

recensione ultra-quick
----------------------
si tratta di un analizzatore dinamico di codice, ed e' piu' o meno
equivalente all'assai piu' noto Valgrind: http://valgrind.org/

la cosa *molto* interessante e' che Dr. Memory gira indifferentemente
sia su Windows (32 bit) sia su Linux e persino sotto Mac OsX, mentre
invece Valgrind gira esclusivamente su Linux.
finalmente abbiamo un tool completo ed abbastanza sofisticato anche
sulle piattaforme Windows.

detta in due parole, si tratta di strumenti sw che eseguono un
programma qualsiasi al proprio interno tenendo sotto costante
monitoraggio tutte le operazioni che interessano la memoria
dinamica di tipo heap, cioe' quella che in C si gestisce tramite
malloc/free ed in C++ tramite new/delete.
l'unico pre-requisito richiesto e' che il programma bersaglio
va compilato in modo un po' speciale, in modo tale da conservare
all'interno dell'eseguibile tutti i numeri di linea che consentono
di risalire al punto esatto del sorgente che causa il problema.

nel 99% dei casi i bugs veramente rognosi da identificare e
risolvere (quelli che accadono in modo apparentamente capriccioso
e magari difficile da riprodurre in modo deterministico) affondano
le proprie radici profonde proprio in quest'area critica.
ecco spiegato perche' un tool diagnostico di questo tipo e' un
vero e proprio toccasana che consente di arrivare a distribuire
codice molto robusto e stabile a prova di bomba.

le condizioni pericolose da tenere sempre sotto stretto controllo
rientrano nelle seguenti categorie:

- memory leaks: il programma alloca blocchi di memoria dinamica
  che poi si dimentica sbadatamente di liberare quando non servono
  piu'. la conseguenza negativa e' in questo modo pian piano la
  memoria si esaurisce, le performances peggiorano progressivamente
  ed infine si puo' anche arrivare ad un bel crash per esaurimento
  delle risorse.
  e' una condizione decisamente pericolosa per tutte le app con
  una GUI, ma e' ancor piu' nefasta per i processi server che
  restano ininterrottamente in esecuzione anche per mesi e mesi.

- buffer overflow: il programma alloca p.es. 1000 bytes, ma poi
  all'atto pratico cerca di leggerne o scriverne un po' di piu'
  (p.es. 1005) finendo cosi' per sfondare i limiti dell'allocazione.
  la cosa finisce assai spesso con qualche bel fuoco di artificio :-)

- memoria non inizializzata: il programma dimentica di assegnare
  esplicitamente un valore iniziale opportuno ai blocchi di memoria
  dinamica che alloca via via.
  dopo di che il primo tentativo di utilizzare comunque quei dati
  puo' facilmente causare effetti stravaganti e bizzarri.
  di fatto questo e' il meccanismo tipico che sta alla base di piu'
  o meno tutti i "bugs misteriosi", quelli che "accade solo una
  volta su mille", "accade solo sul PC di Giorgio, su tutti gli
  altri PC funziona sempre perfettamente" o magari "su Linux gira
  sempre bene, invece su Windows spesso va in crash ma a volte
  funziona normalmente, dipende da come gli gira".

usare regolarmente tools come Valgrind o Dr. Memory semplifica
notevolmente il compito di identificare e poi risolvere tutti
i pasticci e pasticcetti di questa natura.
ecco spiegato perche' questi strumenti dovrebbero sempre fare
parte integrante dei normali strumenti di sviluppo e verifica
della qualita' per qualsiasi progetto di sw libero "serio".

venendo piu' nello specifico a Dr. Memory:
* alla prova dei fatti funziona sorprendenemte bene
* l'installazione e' facilissima, cosi' come e' molto facile
  compilare il programma da sottoporre a monitoraggio: basta
  leggersi poche righe chiaramente documentate e praticamente
  parte tutto da solo in cinque minuti.
* su Win supporta indifferentemente sia MinGW che MSVC
* il progetto ha nobilissime ascendenze, visto che si basa su
  DynamoRIO, un toolkit sviluppato inizialmente da HP in
  stretta collaborazione con il prestigioso MIT
* last but not least, e' tutto free sw rilasciato sotto LGPL;
  e' decismanete interessante scoprire che per i primi anni
  ha mosso i propri passi come prodotto proprietario, ma piu'
  di recente e' diventato sw libero a tutti gli effetti.
  Evviva il figliol prodigo :-D

ciao Sandro

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015

[geodrinx]

Alessandro,

ho provato a "testare" QGIS ma DrMemory mi dice che non funziona sui 64 bit.  :(

Tu sai se c'é un installer di DrMemory 64 per Windows ?

Ciao e grazie

Roberto

Inviato da iPhone

Il giorno 25/mag/2015, alle ore 11:55, [hidden email] ha scritto:

> visto che e' un tool abbastanza nuovo e non ancora troppo noto
> credo di fare una cosa potenzialmente utile segnalandovi questo
> pacchetto decisamente molto utile.
>
> Dr. Memory http://www.drmemory.org/
>
> recensione ultra-quick
> ----------------------
> si tratta di un analizzatore dinamico di codice, ed e' piu' o meno
> equivalente all'assai piu' noto Valgrind: http://valgrind.org/
>
> la cosa *molto* interessante e' che Dr. Memory gira indifferentemente
> sia su Windows (32 bit) sia su Linux e persino sotto Mac OsX, mentre
> invece Valgrind gira esclusivamente su Linux.
> finalmente abbiamo un tool completo ed abbastanza sofisticato anche
> sulle piattaforme Windows.
>
> detta in due parole, si tratta di strumenti sw che eseguono un
> programma qualsiasi al proprio interno tenendo sotto costante
> monitoraggio tutte le operazioni che interessano la memoria
> dinamica di tipo heap, cioe' quella che in C si gestisce tramite
> malloc/free ed in C++ tramite new/delete.
> l'unico pre-requisito richiesto e' che il programma bersaglio
> va compilato in modo un po' speciale, in modo tale da conservare
> all'interno dell'eseguibile tutti i numeri di linea che consentono
> di risalire al punto esatto del sorgente che causa il problema.
>
> nel 99% dei casi i bugs veramente rognosi da identificare e
> risolvere (quelli che accadono in modo apparentamente capriccioso
> e magari difficile da riprodurre in modo deterministico) affondano
> le proprie radici profonde proprio in quest'area critica.
> ecco spiegato perche' un tool diagnostico di questo tipo e' un
> vero e proprio toccasana che consente di arrivare a distribuire
> codice molto robusto e stabile a prova di bomba.
>
> le condizioni pericolose da tenere sempre sotto stretto controllo
> rientrano nelle seguenti categorie:
>
> - memory leaks: il programma alloca blocchi di memoria dinamica
>  che poi si dimentica sbadatamente di liberare quando non servono
>  piu'. la conseguenza negativa e' in questo modo pian piano la
>  memoria si esaurisce, le performances peggiorano progressivamente
>  ed infine si puo' anche arrivare ad un bel crash per esaurimento
>  delle risorse.
>  e' una condizione decisamente pericolosa per tutte le app con
>  una GUI, ma e' ancor piu' nefasta per i processi server che
>  restano ininterrottamente in esecuzione anche per mesi e mesi.
>
> - buffer overflow: il programma alloca p.es. 1000 bytes, ma poi
>  all'atto pratico cerca di leggerne o scriverne un po' di piu'
>  (p.es. 1005) finendo cosi' per sfondare i limiti dell'allocazione.
>  la cosa finisce assai spesso con qualche bel fuoco di artificio :-)
>
> - memoria non inizializzata: il programma dimentica di assegnare
>  esplicitamente un valore iniziale opportuno ai blocchi di memoria
>  dinamica che alloca via via.
>  dopo di che il primo tentativo di utilizzare comunque quei dati
>  puo' facilmente causare effetti stravaganti e bizzarri.
>  di fatto questo e' il meccanismo tipico che sta alla base di piu'
>  o meno tutti i "bugs misteriosi", quelli che "accade solo una
>  volta su mille", "accade solo sul PC di Giorgio, su tutti gli
>  altri PC funziona sempre perfettamente" o magari "su Linux gira
>  sempre bene, invece su Windows spesso va in crash ma a volte
>  funziona normalmente, dipende da come gli gira".
>
> usare regolarmente tools come Valgrind o Dr. Memory semplifica
> notevolmente il compito di identificare e poi risolvere tutti
> i pasticci e pasticcetti di questa natura.
> ecco spiegato perche' questi strumenti dovrebbero sempre fare
> parte integrante dei normali strumenti di sviluppo e verifica
> della qualita' per qualsiasi progetto di sw libero "serio".
>
> venendo piu' nello specifico a Dr. Memory:
> * alla prova dei fatti funziona sorprendenemte bene
> * l'installazione e' facilissima, cosi' come e' molto facile
>  compilare il programma da sottoporre a monitoraggio: basta
>  leggersi poche righe chiaramente documentate e praticamente
>  parte tutto da solo in cinque minuti.
> * su Win supporta indifferentemente sia MinGW che MSVC
> * il progetto ha nobilissime ascendenze, visto che si basa su
>  DynamoRIO, un toolkit sviluppato inizialmente da HP in
>  stretta collaborazione con il prestigioso MIT
> * last but not least, e' tutto free sw rilasciato sotto LGPL;
>  e' decismanete interessante scoprire che per i primi anni
>  ha mosso i propri passi come prodotto proprietario, ma piu'
>  di recente e' diventato sw libero a tutti gli effetti.
>  Evviva il figliol prodigo :-D
>
> ciao Sandro
>
> _______________________________________________
> [hidden email]
> http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
> Questa e' una lista di discussione pubblica aperta a tutti.
> I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
> 750 iscritti al 18.3.2015

_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015

[a.furieri]

On Tue, 26 May 2015 07:25:19 +0200, Geodrinx wrote:
> Alessandro,
>
> ho provato a "testare" QGIS ma DrMemory mi dice che non funziona sui
> 64 bit.  :(
>
> Tu sai se c'é un installer di DrMemory 64 per Windows ?
>

lo dice chiaramente nelle istruzioni:
"Dr. Memory currently targets 32-bit applications only."

se non erro esiste anche una versione di QGIS a 32 bit (x86); usa
quella, gira sicuramente anche se il tuo PC usa una CPU x86_64

comunque il problema vero e' che se non usi una versione di
QGIS compilata in modo tale da conservare internamente tutti
i numeri di linea dei sorgenti (modalita' debug) otterrai
comunque una diagnostica praticamente incomprensibile e di
ben scarsa utilita'.
i settings da usare per compilare sia sotto MSVC che MinWG
li trovi chiaramente indicati qua:

http://drmemory.org/docs/page_prep.html

ciao Sandro
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015

[Sandro Santilli]

On Tue, May 26, 2015 at 08:15:42AM +0200, [hidden email] wrote:

> On Tue, 26 May 2015 07:25:19 +0200, Geodrinx wrote:
> >Alessandro,
> >
> >ho provato a "testare" QGIS ma DrMemory mi dice che non funziona sui
> >64 bit.  :(
> >
> >Tu sai se c'é un installer di DrMemory 64 per Windows ?
>
> lo dice chiaramente nelle istruzioni:
> "Dr. Memory currently targets 32-bit applications only."

Nemmeno ricompilandolo ? Strano !

--strk;
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015

[a.furieri]

On Tue, 26 May 2015 10:13:28 +0200, Sandro Santilli wrote:

> On Tue, May 26, 2015 at 08:15:42AM +0200, [hidden email] wrote:
>> On Tue, 26 May 2015 07:25:19 +0200, Geodrinx wrote:
>> >Alessandro,
>> >
>> >ho provato a "testare" QGIS ma DrMemory mi dice che non funziona
>> sui
>> >64 bit.  :(
>> >
>> >Tu sai se c'é un installer di DrMemory 64 per Windows ?
>>
>> lo dice chiaramente nelle istruzioni:
>> "Dr. Memory currently targets 32-bit applications only."
>
> Nemmeno ricompilandolo ? Strano !
>

Strk,

pensandoci su non e' poi cosi' tanto strano.

questi tools lavorano come se fossero una virtual machine:
intercettano il codice macchina e lo eseguono in modo indiretto
piu' o meno come se fosse un p-code (infatti introducone sempre
un rallentamento piu' o meno vistoso).
in questo modo riesconoo a tenere traccia di tutti gli indirizzamenti
e possono efficacemente verificare se accadono pasticci strani.

ma amd64 / x86_64 presenta delle grosse differenze rispetto al
vecchio x86 proprio per quanto riguarda l'architettura HW dei
registri di indirizzamento: in particolare supporta la modalita'
"Position Independent Code (PIC)" che non ha equivalenti su x86.
non a caso quando si compila una DLL per amd64 gcc pretende sempre
che venga specificata esplicitamente l'opzione -fPIC

non pare poi cosi' inverosimile che per implementare il supporto
anche per amd64 serva un po' di lavoro extra, che evidentemente
ancora nessuno ha fatto :-P

ciao Sandro
_______________________________________________
[hidden email]
http://lists.gfoss.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non hanno relazione diretta con le posizioni dell'Associazione GFOSS.it.
750 iscritti al 18.3.2015