2009-04-30 7 views
8

Existe-t-il un moyen de trouver les fichiers objets à partir desquels l'exécutable actuel est généré sous Linux (RHEL spécifique). Je comprends que l'on peut utiliser "nm" pour trouver les symboles exportés, "ldd" pour trouver l'objet partagé dépendant.Fichiers objets dans un exécutable sous Linux

Mais je n'ai pas trouvé de commande pour trouver le nom des fichiers objet (.o) dont l'exécutable est composé. C'est possible?

Répondre

6

S'il a été compilé avec les informations de débogage oui. Utilisez gdb (man gdb) pour trouver l'information.

S'il n'a pas été compilé sans informations de débogage. Vous n'avez pas de chance.

1

En plus de nullptr, « objet partagé » fait référence à d'autres bibliothèques partagées (liées), et non à des objets originaux (non liés)

1

Vous pouvez également utiliser objdump (tant que l'exécutable et les objets ont été compilés avec des informations de débogage):

# gcc -g -c -o /tmp/some_object.o /tmp/some_object.c 
# gcc -g -o /tmp/file /tmp/file.c /tmp/some_object.o 
# objdump -g /tmp/file | awk 'BEGIN{out=0} /Directory Table/{out=1} /Line Number Statements/{out=0} {if(out){print $0}}' 
The Directory Table (offset 0x1b): 
    1  /tmp 

The File Name Table (offset 0x21): 
    Entry Dir  Time Size Name 
    1  1  0  0  file.c 

The Directory Table (offset 0x5a): 
    1  /tmp 

The File Name Table (offset 0x60): 
    Entry Dir  Time Size Name 
    1  1  0  0  some_object.c 

awk est utilisé juste pour extraire les informations pertinentes (si vous ne l'utilisez pas, vous obtenez les informations de débogage complète dans l'exécutable et des objets).

4

Les noms d'origine des fichiers objets ne sont pas stockés dans les informations de débogage DWARF. Chaque fichier objet porte une entrée DW_TAG_compile_unit dans la section .debug_info. Cette entrée contient une référence au "fichier source principal à partir duquel l'unité de compilation a été dérivée", mais pas le nom du fichier objet. The DWARF standard contient une liste des attributs qui peuvent être stockés pour chaque unité de compilation (section 3.1.1, page numéro 44, pdf page 58).

Vous pouvez afficher les informations qui sont stockées avec la commande suivante:

$ readelf --debug-dump=info --dwarf-depth=1 hw 

sortie:

Contents of the .debug_info section: 
<some compilation units removed>  
    Compilation Unit @ offset 0x133: 
    Length:  0x8b (32-bit) 
    Version:  4 
    Abbrev Offset: 0x64 
    Pointer Size: 4 
<0><13e>: Abbrev Number: 1 (DW_TAG_compile_unit) 
    <13f> DW_AT_producer : (indirect string, offset: 0x131): GNU C11 5.3.0 -mtune=generic -march=pentiumpro -g 
    <143> DW_AT_language : 12  (ANSI C99) 
    <144> DW_AT_name  : (indirect string, offset: 0x163): hw.c 
    <148> DW_AT_comp_dir : (indirect string, offset: 0x168): /home/mikel/src/hw 
    <14c> DW_AT_low_pc  : 0x80483db 
    <150> DW_AT_high_pc  : 0x2e 
    <154> DW_AT_stmt_list : 0xea 
<1><158>: ... 
<some compilation units removed> 
1

Un fichier objet se traduit par un exécutable après la liaison. Si la liaison est partagée, vous pouvez l'obtenir via des bibliothèques partagées (ldd). Cependant, si la liaison est statique, alors il n'y a qu'un moyen, c'est-à-dire via des informations de débogage. Vous pouvez installer des paquets debuginfo dans RHEL (ou Fedora d'ailleurs). Voici les instructions

Et puis utilisez gdb info sources comme décrit ici:

Cela vous donne une l ist des fichiers sources. Mais pour obtenir réellement les fichiers objet, vous devez regarder plus en profondeur dans les outils de construction (rpmbuild).Et pour exécuter effectivement rpmbuild vous auriez besoin du paquetage RPM source, que vous pouvez obtenir en utilisant les instructions indiquées ici:

Maintenant, vous pouvez construire vous-mêmes paquet et disséquer quel fichier .o a donné dans l'exécutable.

J'espère que cela aide.

Questions connexes