2009-12-29 10 views
6

Se menciona en http://sourceware.org/ml/gdb/2007-06/msg00360.html antes.
Pero nadie parecía haber implementado realmente este tipo de idea.
¿Hay algún obstáculo para hacer esto?¿Alguien sabe si alguien había integrado libsegfault.so y gdbserver para poder adjuntar gdb sobre la marcha a un programa bloqueado?

Mis requisitos son los siguientes: (Ej. Mediante el uso de LD_PRELOAD)

  1. Ser capaz de plug-in a cualquier ejecutable binario ELF
  2. El binario puede ser un multiproceso ejecutable
  3. El binario puede enlazar a una biblioteca que contiene la función del principal
  4. Esto debería funcionar en diversos arquitectura de la CPU que no sea x86 (MIPS, ARM, PPC al menos)

Entonces, si ya hay una solución como esta, quería un enlace, pero si aún no lo he hecho, quería saber por qué aún no está implementado como una rueda.
Podría ser que nadie no lo necesitaba ... pero creo que esto es bastante útil para prepararse como estándar.

Cualquier cuestión técnica o política que no sea solo juntar el código es necesario.

+0

Si ya tiene un archivo de núcleo violación de segmento, se puede conectar el GDB o gdbserver en el fichero de núcleo y obtener la información de depuración. Si no lo hace pero sabe cómo reproducir el bloqueo, puede conectar el pid y verlo segfault. ¿Cómo/qué es esto para ayudar a la depuración? –

+0

Supongo que la idea es que no tengas que cargar gdb [servidor] hasta que el programa realmente se cuelgue, y que mirar una imagen en vivo puede ser más esclarecedor que solo un volcado del núcleo. (No estoy de acuerdo, pero puedo entender el sentimiento.) Más problemáticamente, la ** pregunta ** pregunta "¿es esto posible?" pero OP parece ** esperar ** una solución completa ... – ephemient

Respuesta

9

No parece demasiado difícil.

 
$ ./a.out 
Caught signal at 0x400966: Segmentation fault 
Segmentation fault 
$ GDB_COMM=:1024 ./a.out 
Caught signal at 0x400966: Segmentation fault 
Attached; pid = 2369 
Listening on port 1024 
 
$ gdb ./a.out 
Reading symbols from /home/me/a.out...done. 
(gdb) target remote :1024 
Remote debugging using :1024 
#define _XOPEN_SOURCE 500 
#include <signal.h> 
#include <stdio.h> 
#include <stdlib.h> 
#include <string.h> 
#include <sys/types.h> 
#include <unistd.h> 
static char *gdb_comm; 
static void segv_handler(int sig, siginfo_t *si, void *uc) { 
    pid_t child; 
    char msg[84], pid[20]; 
    char *const argv[] = {"gdbserver", gdb_comm, "--attach", pid, NULL}; 
    sprintf(msg, "Caught signal at %p", si->si_addr); 
    psignal(si->si_signo, msg); 
    if (gdb_comm && *gdb_comm) { 
     switch ((child = fork())) { 
     case 0: 
      sprintf(pid, "%ld", (long)getppid()); 
      execvp(argv[0], argv); 
      perror("Failed to start gdbserver"); 
      _exit(-1); 
     case -1: 
      perror("failed to fork"); 
     default: 
      waitpid(child, NULL, 0); 
      break; 
     } 
    } 
} 
int main(int argc, char **argv) { 
    static struct sigaction segv_action = { 
     .sa_sigaction = segv_handler, 
     .sa_flags = SA_RESETHAND | SA_SIGINFO, 
    }; 
    gdb_comm = getenv("GDB_COMM"); 
    sigaction(SIGILL, &segv_action, NULL); 
    sigaction(SIGFPE, &segv_action, NULL); 
    sigaction(SIGSEGV, &segv_action, NULL); 
    sigaction(SIGBUS, &segv_action, NULL); 
    *(int *)main = 0; 
    return 0; 
} 
+0

Gracias por su respuesta, pero esto no es lo que se esperaba como respuesta. Creo que he cuestionado que "si alguien hubiera integrado libsegfault.so y gdbserver". Quería una razón por la que esto no se haya hecho aún, o una integración correcta (adecuada) entre libsegfault.so y gdbserver. Lo siento por mi pregunta por no ser lo suficientemente detallada, pero los requisitos son: 1. Ser capaz de agregar LD_PRELOAD a cualquier programa 2. El programa puede ser un programa multiproceso 3. El programa puede vincular a una biblioteca que Contiene la función principal – holmes

+0

Esto es solo una prueba de concepto, para demostrar que no creo que haya ningún obstáculo significativo para implementar esto. No debería ser difícil adaptar las ideas a sus especificaciones, y todas las llamadas de sistema necesarias aquí son asincrónicas, por lo que debería estar bien en un programa de subprocesos múltiples. – ephemient

+0

Bueno, creo que esto es obvio. Pensé que podría haber algún otro problema técnico o político para unirlos en glibc. – holmes

Cuestiones relacionadas