GCC - Imprimer la définition d'une structure

Question

Est-il possible qu'un C programme pour imprimer la définition d'une structure ? Les noms des membres seraient très utiles, mais une simple liste ordonnée des types de données (et de la longueur des tableaux dans le cas des tableaux) serait suffisante.

J'ai cherché des directives de préprocesseur pour y parvenir, mais je n'en ai pas trouvé. Existe-t-il une directive du préprocesseur qui puisse récupérer une partie de code annotée et l'utiliser comme une variable #define. Si c'est le cas, je pourrais initialiser quelques variables sting avec pour contenir la valeur des variables #define.

Par exemple, une structure comme celle-ci est imprimée telle quelle

struct foo{
int a;
char b;
short arr[6];
}

ou comme ceci

struct s{
int m1;
char m2;
short m3[6];
}

Le formatage n'est pas important tant que la structure peut être recréée à partir des données. Ce type de document est donc tout à fait acceptable :

s{int,char,short[10]}

Pour information, il s'agit d'un appareil à base d'ARM dont les ressources sont limitées.

Je ne veux pas copier-coller manuellement le code de la structure dans une instruction d'impression. Si le code de la structure est modifié et que l'instruction d'impression ne l'est pas, les résultats seront erronés.

Answer 1

Pourquoi voudriez-vous faire cela si vous avez déjà le code source ?

Mais en général, les compilateurs C n'offrent pas d'option pour, par exemple, "lister" toutes les structures qu'ils ont vues pendant la compilation. Le compilateur conserve des tables de symboles internes, mais personne n'a pensé à la nécessité de pouvoir les imprimer. Il peut également y avoir des centaines de structures et de types dans tous les fichiers source et d'en-tête lus pendant la compilation.

Notez également que les noms des types, des champs et des variables sont principalement là pour donner une signification au programmeur. Après la compilation, de nombreux noms disparaîtront. Seules les variables globales et les variables externes manquantes conserveront leur nom dans le fichier objet afin de pouvoir les résoudre lors de l'édition des liens, et après l'édition des liens, aucun de ces noms n'est plus nécessaire. Le compilateur a par exemple traduit a->b dans l'offset de b se rapporter à l'endroit de la mémoire où a réside.

Answer 2

Il existe des formats de fichiers objets qui contiennent les informations dont vous avez besoin et qui permettent un accès programmatique. L'un d'entre eux est Nain . Les débogueurs utilisent généralement ces informations.

Je ne pense pas (mais je n'en suis pas sûr) qu'il soit possible d'accéder aux informations de débogage pour la fonction code en cours d'exécution . Il s'agit d'une différence par rapport aux programmes dans des langages qui fonctionnent dans un système d'exécution élaboré comme Java ou la famille .net. Ceux-ci peuvent utiliser la réflexion sur eux-mêmes.

Dans les programmes écrits dans des langages traditionnellement compilés, vous ouvrirez probablement un fichier objet, voire l'exécutable lui-même ! -- et l'examiner par programme, un peu comme le fait un débogueur. Il est donc concevable qu'il soit plus facile d'analyser le code source (qui, en C et C++, doit être disponible pour de nombreuses définitions de type sous la forme de fichiers d'en-tête). Mais pour des utilisations non triviales, cette idée peut être trompeuse car le compilateur a lexé et analysé le code source pour vous et a placé toutes les informations dans des structures de données soignées auxquelles il est facile d'accéder. Cette partie du processus de compilation -- c'est-à-dire une partie considérable de la partie frontale -- devrait être faite par vous si vous opérez sur les sources.