Ceci peut être utile ? LIENCitation:
Envoyé par dva2tlse
Version imprimable
Ceci peut être utile ? LIENCitation:
Envoyé par dva2tlse
Tu cherches à faire un debugger, en fait?
por ssmario2, oui merci c'est exactement ce que je cherche; donc je n'ai plus qu'à tester l'existence de telle ou telle macro qui sera là sous linux ou sous sunOS héhop le tour est joué ça me compile ce qu'il faut pour l'OS qui a défini les macros.
pour médinoc, oui cela ressemble un peu à un debugger, dans la mesure où je voudrais consulter la valeur de certaines données en mémoire, et les modifier.
Merci à tous les deux.
As-tu saisi que la compilation se faisait avant l'exécution ?
Non, parce qu'encore une fois c'est un problème de compilateur et pas d'environnement. Le préprocesseur n'a que faire de la machine qui sert à compiler. Dans l'industrie, il est fréquent de faire de la 'cross compilation', c'est à dire de générer du code sur une machine A à destination d'une machine B. La machine B n'a que faire de la machine A. Ce qui importe au compikateur c'est de savoir qu'il est en rain de compiler pour une machine B. C'est tout ce qui compte.Citation:
Je relis et comprends ton énervement apparent à propos de la confusion que je fais entre temps d'exécution contre compilation; donc ce qu'il me faut si ça existe, c'est que le préprocesseur ait un moyen de savoir sur quelle machine il est; existerait il quelque chose comme #getenv() ?
merci.
Tu raisonnes de travers. Prend du recul.
Ouf, j'ai enfin lu aujourd'hui, dans un man de kernel,
que j'avais en fait depuis toujours à ma disposition dans la machines,
ce qu'était exactement le kernel ou noyau : "The operating system image,
or kernel, is the collection of software made up of the core image files
(unix and genunix) of all of the modules loaded at any instant in time.
The system will not function without a kernel to control it."
Mais maintenant pourquoi ce kernel-noyau voit il la structure proc de
mon process en utilisant une adresse virtuelle et non physique ?
Et qu'est cette adresse virtuelle par rapport à l'autre ?
Dynamic address translation (merci gogol et wikipedia)
While executing an instruction a CPU fetches an instruction located at a particular virtual address or fetches data from a specific virtual address or stores data to a particular virtual address, the virtual address must be translated to the corresponding physical address. This is done by a hardware component, sometimes called a memory management unit, which looks up the real address (from the page table) corresponding to a virtual address and passes the real address to the parts of the CPU which execute instructions. If the page tables indicate that the virtual memory page is not currently in real memory, the hardware raises a page fault exception (special internal signal) which invokes the paging supervisor component of the operating system
Cela me rapelle un temps déjà un peu éloigné, où la plus grosse bécane
que j'avais à ma disposition pour tourner mes calculs était un microvax 3100,
auquel j'imagine que des PC actuels doivent mettre une gentille pâtée
en terme de puissance de calcul.
Et sur le vax il y avait un certain fichier PAGEFILE.SYS, fichier de pagination,
dont la taille était assez critique, et avec lequel je me suis pas mal bagarré
pour que mes calculs tournent et le mieux possible. À ce que je sais ça correspond
plus ou mois au fichier de swap des machines nux, et cela constitue cette foutue
mémoire virtuelle dont je cherche à comprendre le pourquoi du comment depuis quelques
temps, à cause de cette foutue structure proc dont je n'ai qu'une adresse qui semble
être virtuelle.
Donc je n'ai peut-être pas besoin de passer par ptrace (ni de m'attirer les foudres d'Émmanuel)
pour lire puis modifier les structures proc et cred qui m'intéressent.
Post sans question puisque j'ai tout compris; David
PS Euh... au fait j'y pense, y aurait il un moyen de convertir l'une en l'autre ?
La structure proc, tu ne la lira pas en allant triffouiller dans l'address space du process qui t'intéresse. Un process n'a pas accès à sa propre structure proc. Lire une structure proc suppose de lire de la mémoire kernel, ce qui peut se faire avec /dev/kmem, ou peut-être avec ptrace (je ne connais pas vraiment ptrace), ou peut-être avec un éventuel system call non documenté qui ferait ça. Il y a une autre personne sur ce forum qui cherche à faire le même genre de truc.
pour matafan :ça c'est embêtant; mais sais tu si une quelconque structure est stockée en mémoire après une certaine en-tête qui me permettrait de la reconnaître, ou veux tu dire que mon process n'a carrément pas accès a ses propres données et qu'il me faut trouver autre chose qu'essayer de la reconnaître dans l'ensemble de la mémoire à laquelle mon processus a accés par memchr ou équivalent ?Citation:
Un process n'a pas accès à sa propre structure proc
Je vais essayer de trouver l'autre type dont tu parles et ses messages.
David
Ah ben non en fait je crois que c'était toi l'autre persone en question :lol:
Ce qui fait que ça fais un mois que je te répète la même chose.
en effet tu t'es déjà adressé à moi il y a plus ou moins un mois dans un autre fil de discussion qui avait également trait aux structures cred et proc, mais il n'avait pas été question qu'un processus n'ait pas accès à sa propre structure proc.
Il n'était question que d'adresse, dont tu me disais que celle que j'obtiens par "ps -o user,pid,addr,args -p PID_de_ma_kshell" était probablement virtuelle, et c'est pour ça que j'ai désormais besoin d'un moyen de conversion vers l'adresse physique pour lire ce qu'elle contient dans un premier temps.
Mais si je ne peux pas y lire ça ne va plus du tout; et cela me semble contraire à ce que j'ai lu dans l'article de bandit qui est ici : http://sobrique.livejournal.com/34889.html . Contrairement au type de l'article je n'ai pas accès à la console, donc je voudrais passer par un programme en C, ce qui m'impose d'apprendre à m'en servir correctement.
David
J'ai parcouru rapidement l'article. Je ne connais pas les environment Sun mais comme il parle de ‘break’ sequence qui ouvre un ‘OK’ prompt, et vu ce qu'il dit ensuite, ça ressemble un peu à KDB (kernel debugger) sur AIX. Je pense que son "OK prompt" lui permet comme KDB de manipuler les données kernel. Mais ce n'est pas le genre de chose que tu peux faire directement en user space.
C'est ce que j'essaie de te faire comprendre depuis le début : on ne peux pas accéder à un structure proc de manière conventionelle en user space. C'est pour ça que je t'ai parlé de /dev/kmem, qui permet d'accéder à la mémoire kernel.
Ensuite je ne sais pas si c'est le cas sur Solaris, mais sous AIX les structures cred sont extrèmement sensibles et "volatiles". On ne peut pas y accéder, même en lecture, sans prendre les locks qui vont bien, sous peine de lire des données bidon.
Quand tu es sur la console (et uniquement quand c'est la console) d'une sun, tu as une combinaison de touche (STOP-A) qui te place dans un interpreteur Forth qui fonctionne indépendamment de l'OS (sur un PC, c'est comme si le BIOS n'etait pas courcircuite la plupart du temps par les OS et comportait un interpreteur Forth). Pas de chance, ca ne marchera pas sans cela.
Bon ben ça a bien l'air d'être mort; alors maintenant il va falloir que j'ouvre un autre fil pour apprendre comment lire ce qui est contenu dans une adresse mémoire passée en argument à un programme, parce que ça a aiguisé ma soif d'apprendre, cette babiole.Citation:
Quand tu es sur la console (et uniquement quand c'est la console) d'une sun [.../...] indépendamment de l'OS
David
Moi, je fais comme ça :
(exécuté dans Code::Blocks)Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23 /* http://emmanuel-delahaye.developpez.com/clib.htm */ #include "ed/inc/sys.h" #include <stdio.h> int x = 1234; int main (void) { static double y = 123.45; char z[] = "Hello world"; int n = 4; int *p = malloc(sizeof *p * n); SYS_dump (&x, sizeof x); SYS_dump (&y, sizeof y); SYS_dump (z, sizeof z); SYS_dump (p, sizeof n); return 0; }
mais évidemment, ça ne concerne que la mémoire du processus.Code:
1
2
3
4
5
6
7
8 00402000 D2 04 00 00 '....' 00402008 CD CC CC CC CC DC 5E 40 '......^@' 0022FF30 48 65 6C 6C 6F 20 77 6F 72 6C 64 00 'Hello world.' 008429D0 F8 0E 84 00 '....' Process returned 0 (0x0) execution time : 0.043 s Press any key to continue.
Le même code exécuté en mode console :
Code:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19 Microsoft Windows [version 6.0.6001] Copyright (c) 2006 Microsoft Corporation. Tous droits réservés. C:\Users\Emmanuel>cd\dev C:\dev>cd hello C:\dev\hello>cd bin C:\dev\hello\bin>cd debug C:\dev\hello\bin\Debug>hello 00402000 D2 04 00 00 '....' 00402008 CD CC CC CC CC DC 5E 40 '......^@' 0022FF30 48 65 6C 6C 6F 20 77 6F 72 6C 64 00 'Hello world.' 00270FA8 70 28 27 00 'p('.' C:\dev\hello\bin\Debug>
Tel quel, ça ne veut rien dire. Une adresse mémoire n'a de sens que dans l'address space d'un process. Il n'y a pas d'adresse "absolue" en user space. Par contre un process A peut tout à fait, s'il a les droits qui vont bien, aller lire (ou même écrire) à l'adresse x d'un process B, par les moyens que je t'ai déjà donné (ptrace ou /proc). A condition bien sûr que x soit une adresse valide dans l'address space de B.
ouh là, merci à vous deux Émmanuel et matafan; alors comme ça, il suffit que je fasse semblant de jeter l'éponge et je me retrouve avec bien ce que je voulais savoir.
merci,
David (qui part une semaine en vacances)(ski, nautique alors, vers Guérande)
Dommage que tu ne sois pas sous Windows. Là, il y a un moyen simple de lire la mémoire d'un process appartenant au même utilisateur que le process qui lit (ou bien, n'importe quel process si tu as le bon privilège d'administrateur).
Mais ça ne te donne pas pour autant accès à la mémoire Kernel... (sous Windows, il s'agit des 2Go supérieurs de la mémoire virtuelle du process: Un process y a accès seulement en mode kernel, et c'est partagé entre tous les process)