Format de fichier principal ELF

Court de creuser par le biais de GDB source, où puis-je trouver de la documentation sur le format utilisé pour créer des fichiers de base?

La ELFE spécification des feuilles de la base du format de fichier ouvert, donc je suppose que cela doit faire partie de la GDB cahier des charges! Malheureusement, je n'ai pas trouvé d'aide à cet égard de GNU gdb documentation.

Voici ce que je suis en train de faire: la Carte des adresses virtuelles pour les noms de fonction dans l'exécutable/bibliothèques qui composent les processus en cours d'exécution. Pour ce faire, je tiens tout d'abord à la figure, à partir de la base, le fichier de la carte à partir de l'espace d'adressage virtuel le nom du fichier exécutable/bibliothèques, puis creuser dans le fichier pour obtenir les informations symboliques.

Maintenant "readelf -un noyau' me dit que presque tous les segments dans le fichier de base sont de type "load" -- j'avais suppose que ce sont les .le texte et les .sev/.les segments de données de tous les participants des fichiers, en plus d'un segment de pile. Sauf ces segments de charge, il ya une note du segment, mais qui ne semble pas contenir de la carte. Alors, comment sont les informations à propos de fichier qui un segment correspond à, stockées dans le fichier de base? Sont ceux de "charger" les segments format d'une manière particulière afin d'inclure les informations de fichier?

source d'informationauteur NoJunkNoNoise

  1. 2

    Pas tellement gdb comme le bfd bibliothèque utilisée par gdbbinutilsetc.

  2. 6

    Le fichier de vidage de mémoire format est d'utiliser le format ELF, mais n'est pas décrite dans les ELFE de la norme. Autant que je sache, il n'y a pas de référence sur ce.

    alors, comment sont les informations à propos de fichier qui un segment correspond à, stockées dans le fichier de base?

    Beaucoup d'informations supplémentaires est contenue à l'intérieur de l'ELFE de notes. Vous pouvez utiliser readelf -n de les voir.

    Le CORE/NT_FILE note définit l'association entre la plage d'adresses de mémoire et de fichiers (+ offset):

    Page size: 1
             Start                 End         Page Offset
0x0000000000400000  0x000000000049d000  0x0000000000000000
    /usr/bin/xchat
0x000000000069c000  0x00000000006a0000  0x000000000009c000
    /usr/bin/xchat
0x00007f2490885000  0x00007f24908a1000  0x0000000000000000
    /usr/share/icons/gnome/icon-theme.cache
0x00007f24908a1000  0x00007f24908bd000  0x0000000000000000
    /usr/share/icons/gnome/icon-theme.cache
0x00007f24908bd000  0x00007f2490eb0000  0x0000000000000000
    /usr/share/fonts/opentype/ipafont-gothic/ipag.ttf
[...]

    Pour chaque thread, vous devriez avoir un CORE/NT_PRSTATUS note qui vous donne les registres de la fil (y compris le pointeur de pile). Vous pourriez être en mesure d'en déduire la position des piles de ce.

    Plus d'informations sur le format de l'ELFE fichiers de base:

  3. 3

    Un core dump de la mémoire image du processus quand il s'est écrasé. Il comprend les segments de programme, la pile, le tas et d'autres données. Vous aurez toujours besoin de l'original de programme afin de donner un sens à la table des matières: les tables de symboles et d'autres données brutes des adresses et des structures dans la mémoire d'image significative.

  4. 2

    Plus d'informations sur le processus qui a généré le fichier de base est stockée dans un ELFE de la note de la section, mais dans un système d'exploitation de manière spécifique. Voir, par exemple, la de base(5) de la page de manuel pour NetBSD.

  5. 2

    Une solution simple à votre problème est peut-être analyser le texte dans le répertoire /proc/$pid/maps pour déterminer quel fichier une adresse virtuelle cartes. Vous pouvez ensuite analyser le fichier correspondant.

    Kenshoto de l'open source VDB (debugger) utilise cette approche, si vous pouvez lire python c'est un bon exemple.