Discussion :

[kaiser92]

Bonjour,

je cherche comment recuperer les valeurs min et max du data segment ou sont stockees les variables statiques et globales, via le linker.
Un symbole defini du style .rwdata$r,...
Ca marche sur ARM, j ai lu la doc du linker pour trouver les symboles.
Avec le Visual C++ 2005 linker, j ai pas trouver.
Vous avez une idee svp?
Je voudrais eviter de le faire dynamiquement en scannant les pages avec VirtualQuery.
Ca doit surement exister, la section RW apparait dans le fichier .map genere par le linker, je voudrais recuperer ces valeurs directement dans mon code.
Merci a tous

[Mac LAK]

Question bête : pourquoi faire ? Cela n'a en général aucun intérêt, sauf pour faire des debuggers et des virus... La première activité est plus que rare, la deuxième est plus que douteuse, il ne reste donc pas grand-chose de "légitime" pour avoir besoin d'un tel outil.

Sinon, ta solution passe plutôt dans la documentation du format PE, à mon avis, car les linkers sont spécifiques à un langage donné... Mais tous doivent se conformer au modèle d'exécutables de Windows, seule base réellement commune à tous les langages.

[kaiser92]

En fait j'ai trouver comment faire sur ARM, en lisant la doc du linker :
http://infocenter.arm.com/help/topic...6g/DUI0206.pdf
page 89.
extern unsigned int Image$$RW$$Limit

Et ca marche bien, donc je voudrais faire pareil en Win32, avec le linker visual c++ 2005 pour le langage C++. Ca doit surement etre faisable je pense.
J'utilise toujours le meme linker.
Merci

[Mac LAK]

Donc, je reprends : ce que permet une chaîne de développement pour l'embarqué, notamment des trucs comme la relocation absolue ou les librairies ROMables, n'a absolument AUCUN équivalent, ni le moindre sens d'ailleurs, dans un environnement desktop comme Windows.

Je te repose donc la question : pour quelle raison as-tu besoin de ça ? Il y a fort à parier que tu sois tombé dans le piège courant qui consiste à tenter d'appliquer une mauvaise solution à un problème initial peu (ou mal) expliqué. Reviens donc au problème initial, afin de savoir s'il n'y a pas une solution native, normale et prévue.

Pour ma part, autant j'ai pu avoir souvent besoin de trucs vicieux sur les binaires sur les cibles embarquées elles-mêmes, autant je n'ai absolument jamais eu besoin de telles magouilles sur Windows... Il y a donc fort à parier que tu partes dans la mauvaise direction.

[kaiser92]

mon premier post repond a ta question en fait :

Je voudrais eviter de le faire dynamiquement en scannant les pages avec VirtualQuery.
Ca doit surement exister, la section RW apparait dans le fichier .map genere par le linker, je voudrais recuperer ces valeurs directement dans mon code.

Voila un helloworld app.exe , j 'ai generer le map file via les options du linker

Start Length Name Class
0004:00000000 0000015aH .data DATA
0004:00000160 0000045cH .bss DATA
0005:00000000 00000028H .idata$2 DATA
0005:00000028 00000014H .idata$3 DATA
0005:0000003c 0000015cH .idata$4 DATA
0005:00000198 0000015cH .idata$5 DATA
0005:000002f4 0000053eH .idata$6 DATA
0006:00000000 00000169H .rsrc$01 DATA
0006:00000170 00000a99H .rsrc$02 DATA

Je voudrais recuperer directement ces valeurs dans mon code, comme je le fais en ARM, pour des raisons de performances.
C'est conceptuellement exactement la meme chose. En arm(symbian), je cree de la meme maniere mon fichier map et il contient les meme entrees.
L'architecture windows(data segment, bss, litteral read-only memory) est tres similaire a ARM.
Donc ma question est tres sensee, donc je voudrais savoir si ces valeurs sont recuperables depuis le linker, ou bien elles sont volontairement rendues non publiques par Microsoft.
Je cherche la doc officielle du linker, je n'ai trouver qu'une doc sur un site prive, qui est incomplete
Merci

[Mac LAK]

mon premier post repond a ta question en fait

Pas vraiment, en fait...

Je voudrais recuperer directement ces valeurs dans mon code, comme je le fais en ARM, pour des raisons de performances.

Et c'est justement là que tu ne réponds pas à la question : en quoi est-ce nécessaire ?? Si c'est pour chopper une variable globale, tu l'as déjà dans le code si elle est correctement exportée, et taper directement dans la RAM n'apporte rien : quand ton programme commence à s'exécuter, il a déjà été chargé par Windows, et donc a été relogé, et les adresses sont "en dur" dans le code ASM produit... Et avant cette phase, tu ne peux absolument RIEN faire car ton processus n'existe pas encore.

Comme je te l'ai dit dans ma première réponse, dans le monde Windows, obtenir ces informations n'a en général aucun intérêt sauf si l'on développe un débugger ou un virus, donc de façon générale des programmes intrusifs. Si ce n'est pas ton cas, alors il y a très certainement une bien meilleure méthode à appliquer. Mais il me faut alors ton BESOIN INITIAL pour te conseiller au mieux.
Typiquement, si c'est pour lire des données stockées "en dur" dans le code (ex : tableau de valeurs, images, etc.), alors Windows fournit un bien meilleur outil : les ressources...

Donc ma question est tres sensee, donc je voudrais savoir si ces valeurs sont recuperables depuis le linker, ou bien elles sont volontairement rendues non publiques par Microsoft.

C'est ce que je t'ai déjà dit : la doc du linker n'offre que peu d'intérêt à ce niveau, la réponse est dans le format des exécutables Windows eux-mêmes et tu as déjà le lien. C'est sur les informations de l'exécutable que se basent des utilitaires comme Dependancy Walker pour en analyser le contenu.

[kaiser92]

merci pour ta reponse, mais je pense que tu ne saisi pas ce que je veux faire.
Est ce que tu arrive a concevoir qu'une variable globale deja initialisee, que je lit tout simplement prend moins de temps que de faire un appel de fonction. Je fait ca des milliers de fois.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

int DATASTART = image.idata$2;

comparer a

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

static char dummy;

VirtualQuery(&dummy, ....)+analyse du resultat.
Le Format PE je le connais, le fichier map que je t'ai deja montrer, presente le layout des regions memoire, qui n'est rien d'autre qu'une partie simplifiee du PE.
Tu trouves les meme infos avec dep. walker que le fichier map.
Moi je cherche a recuperer cette donnee via le linker, comme le fait ARM et des dizaines d'autres OS.
Je voudrais savoir si ce symbole est rendu public par le linker ou pas
La reponse n'est surement pas dans le format PE. Lire la doc entiere du format PE ne va pas m'aider plus que de lire mon fichier map, c'est une question banale de savoir si une fonctionalite systeme est rendue publique ou pas, rien de plus.
Donc si tu savais ou je pourrais trouver la doc. officielle du linker ca m'arrangerais.
Merci bien

[Mac LAK]

merci pour ta reponse, mais je pense que tu ne saisi pas ce que je veux faire.

Ben tu ne l'as toujours pas expliqué non plus... Je t'ai demandé plusieurs fois ton besoin initial, mais tu ne l'as toujours pas exprimé.

Est ce que tu arrive a concevoir qu'une variable globale deja initialisee, que je lit tout simplement prend moins de temps que de faire un appel de fonction. Je fait ca des milliers de fois.

int DATASTART = image.idata$2;

comparer a
static char dummy;
VirtualQuery(&dummy, ....)+analyse du resultat.

Et que penses-tu de la méthode suivante :

Code Fichier .H :

Sélectionner tout - Visualiser dans une fenêtre à part

extern mytype DATA ;

Code Fichier .C :

Sélectionner tout - Visualiser dans une fenêtre à part

mytype DATA = ..... ;

Si tu références DATA, au niveau code assembleur généré, c'est immédiat : l'adresse est chargée directement, pas d'appel de fonctions, pas d'indirections particulières. Un coup de debug en activant l'affichage du code assembleur te le confirmera. Si c'est un problème d'accesseur à des classes, je t'encourage à regarder du côté du LTCG sur MSDN.

Côté mapping virtuel, l'adresse de mapping (= le pointeur C/C++) ne change pas durant la "vie" de la mémoire virtuelle, du moins tant que tu maintiens le lock... Tu peux même choisir l'adresse en question, d'ailleurs, bien que ce ne soit pas spécialement recommandé.

Même en embarqué, je n'ai jamais eu besoin d'aller taper directement dans l'image mémoire de l'exécutable, à l'exception notable des CRC d'intégrité... Et je faisais ça avec des µC tournant à seulement quelques MHz, donc bien loin du niveau de puissance d'un ARM ou d'un Pentium actuel, sans perdre un seul cycle machine inutilement et en restant en C "portable".

Dans ton cas, vu que VirtualQuery sert principalement à gérer la mémoire virtuelle (= déterminée à l'exécution et non pas à l'édition de liens, et dont l'adresse mappée varie à loisir ou presque), franchement, je ne vois absolument pas le rapport avec la choucroute : tu mélanges des données statiques issues de la compilation avec des données non seulement dynamiques, mais en plus pouvant être commutées hors de l'adressage physique... Le mélange d'éléments virtuels (impliquant donc d'énormes volumes de données) avec du hack sauvage d'image mémoire n'est pas spécialement une excellente idée en soi.

Surtout qu'avec VS, tu as d'autres solutions certes non portables (et franchement déconseillées de façon générale), mais largement plus propres : les segments de données nommés (#pragma data_seg), le mot-clé __based, et pour l'optimisation d'accès tu as l'alignement global... Sachant qu'en plus, la mémoire partagée "normale" est supérieure aux segments nommés dans le sens où c'est compatible avec d'autres langages, au moins.

Tout ça, c'est du code et/ou du Win32 et/ou de la configuration du linker, et là encore, la tripaille interne du linker n'a absolument aucun intérêt.

Donc si tu savais ou je pourrais trouver la doc. officielle du linker ca m'arrangerais.

L'officiel chez MS, c'est sur MSDN. En général, quand tu ne trouves pas la doc sur MSDN, c'est qu'elle n'existe pas, tout simplement. Tu peux bien sûr trouver la doc des options du linker, c'est évident, et elle est même très détaillée. Mais côté tripaille, c'est directement la doc PE / COFF, car c'est le format devant être respecté en sortie du linker. Et la moulinette pour y arriver n'a pas d'importance.

Comme je te l'ai dit, cela n'offre en général aucun intérêt de faire ça, surtout pas pour les perfs. L'intérêt est dans l'analyse / monitoring / hook d'un exécutable existant, et encore : l'API de débuggage existe et est en général plus efficace qu'un tripotage manuel de l'image mémoire.

Après, à toi de voir, mais si tu n'expliques pas mieux ton besoin initial, je ne pense pas que tu auras ce que tu cherches.

[kaiser92]

En fait tu ne saisi malheuresement pas mon besoin(il est inutile d'expliquer que j'optimise un garbage collector en fait).
Une fois de plus mon besoin minimum le voila :
Je cherche l'adresse du debut du segment et sa fin, de maniere statique.
static char dummy;
VirtualQuery(&dummy, ....)+analyse du resultat.
Permet de recuperer l'addresse de debut du segment, ainsi que la fin.
static char dummy est stoke dans le segment, VirtualQuery a *tout* a voir avec la choucroute. VirtualQuery ne sert pas qu'a la memoire virtuelle comme tu le pense, meme si son nom l'indique.
Cela est tres lent meme si ca marche bien, je veux utiliser le linker pour recuprer les addresse de start et end du segment directement.
J'ai reussi a le faire pour plusieurs OS a part Win32/WinCE.
En symbian par exemple, il est possible de recuperer ces valeurs dynamiquement(avec une fonction systeme equivalente au VirtualQuery). Mais comme c'est lent, j'ai directement recuperer SEGMENT_START et END avec le linker(qui me donne exactement les meme valeurs qu'avec le virtualQuery)
C'est un probleme d'optimisation rien d'autre. J'ai reussi a trouver cela pour tous les OS sur lesquels tourne mon garbage collector, en lisant la doc du linker, mais pas Windows.
La solution est peut etre du coter de #pragma data_seg.
Voila tout
Merci

[Mac LAK]

En fait tu ne saisi malheuresement pas mon besoin(il est inutile d'expliquer que j'optimise un garbage collector en fait).

D'où l'intérêt de toujours expliquer son besoin... Tu n'as pas idée du nombre de "problèmes" exposés par des membres qui, une fois le besoin initial exprimé, ne sont PLUS des problèmes du tout : le souci est quand on commence à chercher une "solution", que l'on tombe sur un os, et que l'on demande à faire sauter le point sur lequel on bute. Alors que la "bonne" méthode est d'avoir une approche différente dès le départ...

VirtualQuery ne sert pas qu'a la memoire virtuelle comme tu le pense, meme si son nom l'indique.

Disons plutôt que l'analyse des droits des segments statiques n'est pas franchement son but premier... Ni ce pour quoi il est le plus efficace, d'ailleurs.

Cela est tres lent meme si ca marche bien, je veux utiliser le linker pour recuprer les addresse de start et end du segment directement.

Question : ceci n'est à faire qu'une seule et unique fois dans la vie du programme... En est-tu réellement à ce point, sachant que dans ce cas, tu ne vas en fait optimiser que l'initialisation de ton programme ?

C'est un probleme d'optimisation rien d'autre. J'ai reussi a trouver cela pour tous les OS sur lesquels tourne mon garbage collector, en lisant la doc du linker, mais pas Windows.

Ce qui est un peu normal, vu que tu peux avoir plusieurs sections BSS (cf. doc du format PE), et donc absolument aucune garantie sur le fait que ces données soient contigües...

La solution est peut etre du coter de #pragma data_seg.

Ou des tas privés, pour faire encore plus simple : c'est la solution idéale sous Windows pour gérer la mémoire tranquillement, vu que tu peux ensuite y faire ce que tu veux (notamment utiliser HeapWalk dessus en tâche de fond).

[kaiser92]

Merci pour ton aide, pour etre honnete j'evite de dire mon besoin initial, car on me guide souvent vers des solutions trop radicale, tout refaire.
Je vais jeter un oeil a la doc du linker, et essayer de trouver un symbole pour le segment et regarder les pragma dataseg, voir si je trouve un truc interessant.
Je ne veux pas utiliser les tas prives, cela est beaucoup trop radical pour un simple probleme de performances.
Mon but est d'enlever du code(avec les virtualQuery) et remplacer par un symbole.
Merci bien

[Mac LAK]

Merci pour ton aide, pour etre honnete j'evite de dire mon besoin initial, car on me guide souvent vers des solutions trop radicale, tout refaire.

A titre informatif et pour "culture personnelle", c'est quelque chose qui signifie souvent que tu as de grosses erreurs dans ta conception... Si tu n'acceptes pas, parfois, de comprendre et/ou reconnaître que ta solution initiale est loin d'être optimale, tu ne progresseras pas.
Écrire un programme portable, cela s'apprend, et c'est loin d'être aussi simple que "respecter deux normes et utiliser des fonctions standards" !

Notamment, il faut bien comprendre que la programmation système portable est un vrai enfer par moments, qui oblige à avoir plusieurs versions existant simultanément. En gros, tu te retrouves à peu de choses près avec des modules "spécifiques", réalisant leur boulot de façon totalement différente d'un OS à l'autre, mais respectant la même interface "publique". C'est ainsi que sont faits la plupart des frameworks de portage, d'ailleurs. Et c'est une condition souvent cruciale pour obtenir des performances maximales quel que soit l'OS...

Je ne veux pas utiliser les tas prives, cela est beaucoup trop radical pour un simple probleme de performances.

C'est pourtant LA solution idéale... Peu de gens savent que Windows permet, via ce mécanisme, d'avoir un GC sur n'importe quel langage capable d'appeler l'API Win32, et ceci sans avoir à se retaper manuellement des fonctions d'allocation.

Mon but est d'enlever du code(avec les virtualQuery) et remplacer par un symbole.

Je pense que tu n'as pas bien saisi un point crucial : tu ne peux pas être certain qu'il n'existe qu'un seul et unique segment (BSS notamment) dans ton image... Ce qui, forcément, fait foirer ton principe qui voudrait que ce segment soit unique.

De plus, tu n'as pas répondu à ma question : l'appel à VirtualQuery n'est nécessaire qu'une seule et unique fois, donc est-ce si important que ça de gagner 500 ms à l'initialisation du programme ??

[wadabush]

Bonjour,

Je me permet de remonter le sujet, car il m’intéresse particulièrement.
Je recherche moi aussi a parcourir mon (mes) data(s) section(s), dans le but de rechercher des références sur des pointeurs (dans un but de DEBUG).

J'ai aussi essaye la méthode proposée par kaiser92 (virtual query), mais comme répondu par Mac LAK, etant donne que j'ai plusieurs dll dans mon programme, je me retrouve avec plusieurs data sections...

Y'a t-il une méthode(propres ou non), pour récupérer la liste des zones mémoires de ces datas sections sans devoir me faire un virtual query sur toutes mes globales?

Concernant le tas prive, je ne suis pas contre, mais en quoi cela va m'aider? Si vous pouviez m'expliquer comment utiliser l'API window, et que cela doivent m'aider, je ne suis pas contre!

Merci d'avance!

[Neitsa]

Bonjour,

Tu peux traverser la listes des modules de ton process via Module32First() et Module32Next() après avoir créé un snapshot avec CreateToolhelp32Snapshot().

Cf. ce code:

Traversing the Module List:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Pour chaque module, tu récupères l'adresse de base ("me32.modBaseAddr" dans l'exemple) qui est un pointeur vers la base du module et donc vers le PE header.

Ensuite tu parses le PE header pour retrouver la liste des sections:

IMAGE_FILE_HEADER.NumberOfSections donne le nombre de sections.

c.f. IMAGE_FILE_HEADER Structure:
http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx

Ensuite dans le PE header tu trouvera les section headers (un tableau) qui recense les headers de sections (adresses, tailles, caractéristiques, etc.). Chaque élément est une structure IMAGE_SECTION_HEADER, au nombre de IMAGE_FILE_HEADER.NumberOfSections.

cf. IMAGE_SECTION_HEADER Structure:
http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx

Le champ "VirtualAddress" est une RVA (Relative Virtual Address) vers la section elle-même, en mémoire (donc pour avoir un pointer c'est: me32.modBaseAddr + IMAGE_SECTION_HEADER.VirtualAddress)

Le champ "Characteristics" indique le type de la section. IMAGE_SCN_CNT_INITIALIZED_DATA et IMAGE_SCN_CNT_UNINITIALIZED_DATA indiquent des sections de data "pures" (utilises un bitwise AND pour récupérer le type), mais avec les optimisations compilos on trouve aussi des données dans les sections de codes...

De là, avec un pointeur sur la section et son type tu peux parser comme tu le souhaites.