Newsgroup: it.comp.os.linux.development
Titolo: Simboli esterni in una libreria

Supponiamo di avere una libreria che definisca la funzione do_stuff(), e
che il codice sia qualcosa del tipo:
void do_stuff() {
     ...
     ...
     foo()
     ...
}
Dove foo() č una funzione definita in un'_altra_ libreria, diciamo
FooLib.
Da qualche parte deve quindi essere scritto che "foo()" significa "il
foo() di FooLib". 
A me servirebbe sia poter leggere questa associazione, sia magari poter
modificare questa informazione.
Il problema che ho č di una libreria C/C++ distribuita solo come codice
oggetto, e che richiede l'installazione sotto /usr/i486-glibc20-linux/
di tutta un'altra versione di glibc e relativo gcc, una cosa piuttosto
sporca che preferirei non fare. Se uso una versione di glibc piů
recente, capitano degli occasionali segmentation fault, e chi li ha
tracciati dice che č un problema con sprintf() o qualcuna della stessa
famiglia.
Leggere le informazioni contenute nella libreria non mi basterebbe certo
per risolvere il problema, ma se non riesco a fare nemmeno quello non
credo di poter far nulla.
Non so nemmeno come risolvere il problema in modo pulito (l'unica cosa
che ho pensato č una nuova sprintf() che faccia da wrapper e sanitizer
verso la sprintf() della mia versione di glibc), ma se non so nemmeno
chi chiama chi e quando...
Mi rendo conto che questo post č abbastanza contorto, ma non so proprio
dove trovare la descrizione completa del processo per cui, a partire da
hello.c, qualcuno scrive le informazioni di linking e qualcun altro le
recupera a tempo di esecuzione e secondo quali passaggi.
-- 
Per rispondermi, ricordati di togliere il 
nome del poeta e il trattino.

 chi chiama chi e quando...
Potresti appunto pensare a un override della sprintf() di glibc 
facendone chiamare una scritta da te. Non ricordo i dettagli del 
procedimento, percio` ti posso solo consigliare una sessione Google con 
parole chiave come "linker" e "preload".
Ciao
  David
-- 
<d.santinoli presso mi. flashnet. it>

Scusa, ma quando linki il programma, non devi usare la direttiva 
-lFooLib? Invece di usare FooLib standard, che il linker andrà a 
cercarsi nelle locazioni standard, mettici il path. E linka staticamente.
Saluti

cercarsi nelle locazioni standard, mettici il path.
Non hai capito: la libreria che uso (quella che hanno costruito con una
versione di glibc vecchia) è solo in forma di codice oggetto, e non
posso ricompilarla, mentre DEVO usarla in quel modo perchè non è
disponibile in formato sorgente. Posso invece sperare di modificare la
tabella di simboli presente al suo interno, in modo che ESSA sia linkata
dinamicamente non con FooLib ma con Sanitized-FooLib.


parole chiave come "linker" e "preload".
Ok, grazie.



Sinceramente questa ipotesi non mi stupirebbe. Si potrebbe provare a creare
due librerie che esportano la stessa funzione
e provare a linkare un programma ad entrambe.
Non ho mai provato ma secondo me non funziona.
--
Alessandro Staltari
staltari(a)
geocities.com

Un programmatore dovrebbe sempre evitare cose difficili. Comunque 
per fare quello che dici tu è necessario modificare il file oggetto (in
formato ELF) della libreria in questione. In particolare ti interessa
modificare la sezione ".dynamic" del file ELF. Che io sappia non
esistono
tool che ti permettano di fare questa operazione direttamente, ma devi
ricorrere a qualche stratagemma (tipo usando hexdump e compagni) o 
devi a farti mano (!!!) un programma che usa la libreria "libelf" e
modifica la
sezione ".dynamic" della libreria. Per vedere il contenuto di questa
sezione
ti basta semplicemente usare il tool "objdump" passandogli l'opzione
"-x" e il nome della libreria.
In bocca al lupo!
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

modificare la sezione ".dynamic" del file ELF. 
[...]
Grazie per le informazioni, certo che la prospettiva č brutta :-)))
