costruzione di un .so che è anche un eseguibile

Question

Quindi, tutti sanno probabilmente che /lib/libc.so.6 di glibc può essere eseguito nella shell come un eseguibile normale in quali casi esso stampa le proprie informazioni di versione ed esce. Questo viene fatto attraverso la definizione di un punto di ingresso nel .so. Per alcuni casi potrebbe essere interessante utilizzare questo per altri progetti. Purtroppo, il punto di ingresso a basso livello è possibile impostare per l'opzione -e di ld è un po 'troppo di basso livello: il caricatore dinamico non è disponibile in modo non è possibile chiamare qualsiasi funzione di libreria corretta. glibc per questo motivo implementa la chiamata di sistema write () tramite una chiamata di sistema nudo in questo punto di ingresso.

La mia domanda ora è, qualcuno può pensare ad un bel modo di come si possa creare un semplice linker dinamico completo da quel punto di ingresso in modo che si possa accedere alle funzioni da altri .so di?

Answer 1

Costruire la propria libreria condivisa opzione -pie con sembra darvi tutto quello che volete:

/* pie.c */
#include <stdio.h>
int foo()
{
  printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
  return 42; 
}
int main() 
{ 
  printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
  return foo(); 
}


/* main.c */
#include <stdio.h>

extern int foo(void);
int main() 
{ 
  printf("in %s %s:%d\n", __func__, __FILE__, __LINE__);
  return foo(); 
}


$ gcc -fPIC -pie -o pie.so pie.c -Wl,-E
$ gcc main.c ./pie.so


$ ./pie.so
in main pie.c:9
in foo pie.c:4
$ ./a.out
in main main.c:6
in foo pie.c:4
$

P.S. glibc implementa write(3) tramite chiamata di sistema, perché non ha nessun altro posto da chiamare (è il più di livello già). Questo non ha nulla a che fare con l'essere in grado di eseguire libc.so.6.

Answer 2

Suppongo che avresti avuto la tua punto ld -e ad un punto di ingresso che sarebbe poi utilizzare la famiglia dlopen() di funzioni per trovare e bootstrap il resto del linker dinamico. Naturalmente ci si deve assicurare che dlopen() stesso è stato sia collegata in modo statico o potrebbe essere necessario implementare abbastanza della propria linker stub per arrivare a questo (utilizzando interfacce chiamata di sistema quali mmap() proprio come libc si sta facendo.

Niente di tutto questo suona "bello" a me. In realtà solo il pensiero di lettura delle fonti di glibc (e il codice sorgente ld-linux, come un esempio) sufficiente per valutare la dimensione del lavoro sembra abbastanza canuto a me. Potrebbe anche essere un incubo portabilità. Ci possono essere grandi differenze tra il modo di Linux implementa ld-linux e come i collegamenti sono fatte sotto OpenSolaris, FreeBSD, e così via. (Non so).