Discussion :

[dva2tlse]

Bonjour,
ma question concerne une machine sun fire 68000 sous sunOS 5.8; je voudrais savoir comment faire pour convertir une adresse kernel virtuelle qui vaut ADDR en une adresse physique que je note addr.

Et ensuite, comment faire pour voir, en C, ce que contient cette case mémoire ?

Selon ce que je sais du contenu de la case mémoire, et éventuellement des suivantes, je compte utiliser un des pointeurs suivants :
int *pint;
float *pfloat;
long *plong;
long long *pll;

Mais comment faire pour donner au pointeur que j'utilise la valeur addr précédemment déterminée ?
Suffit il de faire (par exemple) pfloat=addr;

Et ensuite pour le déréférencer et voir le contenu de addr, puis je faire ceci :
printf("addr vaut %d et contient %f.\n", addr, *pfloat);

Ça fait plein de questions dans un seul post, mais je suis vraiment bloqué à ce niveau de débutant,
merci de m'aider,
David

[Emmanuel Delahaye]

ma question concerne une machine sun fire 68000 sous sunOS 5.8; je voudrais savoir comment faire pour convertir une adresse kernel virtuelle qui vaut ADDR en une adresse physique que je note addr.

Ce n'est absolument pas une question de langage C, mais de programmation système sous ton OS particulier.

http://www.developpez.net/forums/f55...tres-systemes/

Et ensuite, comment faire pour voir, en C, ce que contient cette case mémoire ?

Si il s'agit d'une adresse, elle doit être dans un pointeur. On utilise alors printf() avec "%p" et le cast (void *)

Exemple :

Code :

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

1
2
3
4
5
6
7
8
9
10
#include <stdio.h>
 
int main (void)
{
   int x;
   int *p = &x;
 
   printf ("p = %p\n", (void *) p);
   return 0;
}

Code :

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

1
2
3
4
p = 0022FF44
 
Process returned 0 (0x0)   execution time : 0.033 s
Press any key to continue.

Selon ce que je sais du contenu de la case mémoire, et éventuellement des suivantes, je compte utiliser un des pointeurs suivants :
int *pint;
float *pfloat;
long *plong;
long long *pll;

Mais comment faire pour donner au pointeur que j'utilise la valeur addr précédemment déterminée ?
Suffit il de faire (par exemple) pfloat=addr;

Cette manière d'initialiser un pointeur ne fait pas partie des manières décrites par le langage C. Le comportement est donc indéfini.

Ce peut être techniquement possible, mais rien ne dit que le résultat sera valide. Je n'ai pas bien compris ce que tu cherches à faire, mais les OS modernes interdisent à un processus d'accéder aux données d'un autre processus.

Et ensuite pour le déréférencer et voir le contenu de addr, puis je faire ceci :

Code :

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

  printf("addr vaut %d et contient %f.\n", addr, *pfloat);

Code :

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

  printf("addr vaut %p et contient %f.\n", (void *) pfloat, *pfloat);

mais sans aucune garantie de fonctionnement, notamment si la valeur de addr appartient à un autre processus...

[dva2tlse]

Merci Émmanuel,
je devine que tu penses à un autre post que j'ai fait, où il est effectivement question de plusieurs processus dont j'aimerais que l'un d'entre eux puisse lire certaines donnés d'un autre, et même si possible les modifier.
Cependant ici je voudrais juste combler partiellement mes assez profondes lacunes en C, mais ta réponse ne m'éclaire pas sur les choses suivantes :

"Cette manière d'initialiser un pointeur ne fait pas partie des manières décrites par le langage C. Le comportement est donc indéfini."

Comment faut-il donc faire pour initialiser un pointeur à une valeur qu'on veut lui imposer ?
David
PS: je vais effectivement me tourner vers le forum Solaris pour ma question qui ne concerne pas exactement Solaris.

[Emmanuel Delahaye]

je devine que tu penses à un autre post que j'ai fait,<...>

Je ne sais pas. Je réponds sur plusieurs forums et je ne lis pas les pseudos. je ne lis que la question. De plus je n'ai aucune mémoire, pour ça ...

Comment faut-il donc faire pour initialiser un pointeur à une valeur qu'on veut lui imposer ?

Ca dépend de l'implémentation. Lire la doc de ton compilateur.

Souvent, ceci fonctionne :

Code :

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

1
2
 
T *p = (T*) 12345;

Evidemment, il faut que 12345 soit un entier qui représente une adresse valide du processus courant. Si ce n'est pas le cas, le comportement est indéterminé.

En principe, on a pas à faire ce genre de manip (et tout est fait coté système, pour la rendre caduque...). Je ne comprends toujours pas ce que tu veux faire, et je crois que tu n'as toujours compris qu'on ne pouvait pas accéder aux données d'un autre processus.

[matafan]

Merci Émmanuel,
je devine que tu penses à un autre post que j'ai fait, où il est effectivement question de plusieurs processus dont j'aimerais que l'un d'entre eux puisse lire certaines donnés d'un autre, et même si possible les modifier.

Tu cherches à faire quoi exactement ? Si tu veux que des données soient accessibles à deux processus, la bonne solution est de les placer en mémoire partagée.

Maintenant, si tu veux depuis un processus A accéder à n'importe quelle donnée d'un processus B, c'est une autre histoire, mais en tout cas le coup de passer par une adresse physique n'est clairement pas la bonne solution. Je vois deux solutions :

1) Utiliser ptrace()

2) Utiliser /proc. Sous /proc/PID tu as un fichier qui représente l'adress space d'un processus. Si tu as les droits, tu peux lire et même modifier ce fichier. Pour accéder depuis un processus A à une donnée située dans un processus B à l'adress b, il suffit de lire/écrire dans ce fichier à l'offset b.

[souviron34]

il y a aussi simplement utiliser la partie commune disque (les COMMON en Fortran, Pascal, et autres).

Il existe physiquement une partie système qui est reservée spécifiquement...

Le tout est de trouver comment y accéder avec ton OS et/ou ton langage...

[Emmanuel Delahaye]

Il existe physiquement une partie système qui est reservée spécifiquement...

C'est pas sûr du tout... Ca dépend complètement du système.

[souviron34]

C'est pas sûr du tout... Ca dépend complètement du système.

Et si tu prends un compilo Fortran, tu dois bien pouvoir déclarer des COMMON BLOCK DATA non , puisque c'est dans le langage ?

Donc vraisemblablement sur tous les OS où un compilo Fortran est dispo...

[Emmanuel Delahaye]

Et si tu prends un compilo Fortran, tu dois bien pouvoir déclarer des COMMON BLOCK DATA non , puisque c'est dans le langage ?

Donc vraisemblablement sur tous les OS où un compilo Fortran est dispo...

Je ne connais pas FORTRAN et je n'ai pas le souvenir d'une telle chose en Pascal. Quelle est la spécification de cette zone de données ? Ce n'est pas l'équivalent de la mémoire partagée entre processus (SHM) ?

[souviron34]

Je ne connais pas FORTRAN et je n'ai pas le souvenir d'une telle chose en Pascal. Quelle est la spécification de cette zone de données ? Ce n'est pas l'équivalent de la mémoire partagée entre processus (SHM) ?

si, sauf que c'est sur disque dur. Pas besoin de synchro et d'autre choses... Les déclarations de variables font que ce bloc est reservé par le système (bloc nommé), et accessible par tous les processus le déclarant. Tout programme modifiant une des valeurs la modifie automatiquement pour les autres..

L'instruction COMMON existe aussi en Pascal, bien que peu (pas) documentée / enseignée / utilisée.

EDIT :

je ne suis pas certain (cela fait longtemps que je n'ai plus programmé en Fortran) que le partage puisse se faire entre processus... mais il me semble... En tous cas je suis certain que c'était physiquement situé sur le disque dur.

Et en ce qui concerne Pascal, c'était le cas il y a 15 ans. Je n'ai plus pratiqué depuis, il est possible (vraisemblable ?) que cela n'existe plus. Je me souviens que j'avais eu beaucoup de mal à trouver, mais cela existait.. Je pourrais sans doute retrouver la référence si cela intéresse quelqu'un...

[dva2tlse]

Merci beaucoup à tous les trois, matafan, Émmanuel et souviron34, de vous être penchés sur mon histoire.
Je confirme qu'en fortran, que je connais bien mieux que le C, les COMMON sont des blocs d'echange qui peuvent passer par le disque, mais je n'ai jamais eu vent que ça puisse servir d'un processus à l'autre.
Par contre la mémoire partagée dont vous parlez à plusieurs reprises, ça me fait une piste d'investigations dont je ne souçonnais même pas l'existence.
en tous cas merci encore à tous les trois, mais je viens d'apprendre aujourd'hui que je ne travaillerai peut-être plus à l'avenir avec cette fameuse bécane, donc le problème reste en suspens quelques jours.
David

[dva2tlse]

Bonjour à tous; pour matafan et souviron34 qui sont déjà intervenus dans ce fil de discussion, sachez que je l'ai "un tout petit peu" poursuivi ici (http://www.developpez.net/forums/d65...uestions-pave/).
Et je me suis aperçu ce matin au boulot, où j'ai appris finalement que je risquais de n'être en face de l'émulateur de la sun fire que jusqu'à Noël, puis je devrais basculer sur une AIX, donc matafan pourra me conseiller, mais je ne crois pas qu'il y ait dans cet OS de structure cred qu'on puisse modifier une fois qu'on l'a trouvée, donc il faudra que je trouve autre chose après quoi assouvir ma soif d'apprendre.
Ceci dit, je me suis aperçu ce matin que ce que je cherchais à faire pour consulter la structure proc d'un process et y lire l'adresse de la structure cred de ce même process pour essayer de la changer, ...donc tout cela n'est jamais que de l'édition de mémoire, ce qui ne devrait pas être sorcier à faire.
Alors j'ai juste besoin de savoir comment faire pour lire ce que contient une certaine case mémoire dont j'ai l'adresse sous un forme ou une autre.
David

[Emmanuel Delahaye]

Ceci dit, je me suis aperçu ce matin que ce que je cherchais à faire pour consulter la structure proc d'un process et y lire l'adresse de la structure cred de ce même process pour essayer de la changer, ...donc tout cela n'est jamais que de l'édition de mémoire, ce qui ne devrait pas être sorcier à faire.
Alors j'ai juste besoin de savoir comment faire pour lire ce que contient une certaine case mémoire dont j'ai l'adresse sous un forme ou une autre.
David

J'ai rarement vu quelqu'un d'aussi têtu... On se tue à t'expliquer que dans les systèmes modernes tout est mis en oeuvre pour que la mémoire soit segmentée par processus (Memory Management Unit ou MMU) et que tout débordement soit sanctionné, et tu insistes, pour des raisons obscures, à vouloir essayer de passer outre... Tu n'as vraiment rien d'autre à faire ?

[dva2tlse]

Mais oui bien sûr que je suis têtu, même que j'ai pris un sérieux coup sur la tête qui à fait six semaines et demie de coma il y a bientôt quinze ans, et ça n'a même pas réussi à me casser complètement la calebasse tellement elle est dure. (ce dont je ne suis tout de même que moderément fier parce que c'est parfois pesant pour ne pas dire plus...)
Cet aparté mis à part, il existe bien des choses comme hexedit qui font grosso-modo ce que je veux; donc en demandant ici je tente d'éviter d'avoir à me plonger dans les sources de cette chose qui risquent d'être un peu obtuses pour moi.
En utilisant ptrace et en créant un process fils de celui qui inspecte, je devrais bien avoir le droit de scrutationner ce qui m'intéresse, mais il me manque de savoir comment.
David

[Emmanuel Delahaye]

Cet aparté mis à part, il existe bien des choses comme hexedit qui font grosso-modo ce que je veux; donc en demandant ici je tente d'éviter d'avoir à me plonger dans les sources de cette chose qui risquent d'être un peu obtuses pour moi.

Faut savoir ce que tu veux...

En utilisant ptrace et en créant un process fils de celui qui inspecte, je devrais bien avoir le droit de scrutationner ce qui m'intéresse, mais il me manque de savoir comment.

J'ai du mal à comprendre ce qui t'intéresse vraiment...

Ca y'est, la mémoire m'est revenue...

http://www.developpez.net/forums/d60...ession-telnet/

Tu cherches vraiment à faire des choses bizarres...

[dva2tlse]

Oui Émmanuel, il y avait ça :

Ca y'est, la mémoire m'est revenue...

http://www.developpez.net/forums/d60...ession-telnet/

Tu cherches vraiment à faire des choses bizarres...

oui pour les choses bizarres, mais j'ai abandonné (sans y être arrivé) l'idée de réinventer la roue puisque ma nana m'a convaincu que c'était inutile quand c'est disponible ailleurs, mais il y a aussi ça :

Donc disons que je voudrais changer la valeur du membre cr_uid de la structure cred attachée à la cmdtool (shell dans un fenêtre autonome) que j'ai créée par fork en tant que fille d'un programme en C. (il est bien évident que si j'arrive un jour à modifier ce terme qui donne ses droits à ma shell, je ne ferai pas de bêtises puisque ce serait comme scier la branche sur laquelle je suis assis pour travailler gentiment, mais cela m'impose d'apprendre plein de choses que d'essayer, alors que dix sept ans du même boulot ne me font plus tellement apprendre de nouveauté)

[.../...]

cette adresse est le début de la structure "proc" attachée à la cmdtool-fille, et un membre de cette structure est un pointeur vers la structure cred qui donne les droits à la cmdtool.

Donc ma tête dure me pousse toujours dans la même direction, qui est :
-1°) de forker un petit programme en C,
-2°) de laisser le fils se faire tracer par le père,
-3°) que le père lise l'adresse de la structure proc du fils, (pour l'instant je ne sais obtenir que l'adresse kernel, ou virtuelle, de la structure proc du fils, mais j'ai bon espoir qu'une âme généreuse me présente un moyen de convertir celle ci en adresse physique, par exemple dans ce post où me sont revenus à l'esprit des souvenirs des tout débuts de la micro-informatique personnelle : http://www.developpez.net/forums/d65...nel-virtuelle/ )
-4°) que le pére lise dans cette structure proc l'adresse de la structure cred du fils (par ptrace(PTRACE_PEEKDATA...),
-5°) que le père modifie dans cette structure cred associée au fils le membre cr_uid par ptrace(PTRACE_POKEDATA...),
-6°) puis enfin que le fils crée une cmdtool qui hériterait de ses droits modifiés héhop.
Merci Émmanuel de m'avoir plus ou moins involontairement possé à écrire ce pseudo-code, puisque je vais vite tenter de le faire fonctionner sur mon linux, et dès que je serais au boulot avec la sun au bout de mon émulateur, j'essayerai tout cela.

Mais une petite question quand même dans ce post : comment est il possible qu'un OS se reconnaisse de lui même pour faire la compilation conditionnelle qui convient ?
Pour l'instant j'ai

Code :

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

1
2
// #define LINUX
#define sunOS

et selon celle des deux lignes qui est commentée, chez moi ou au boulot, la compilation crée des programmes un peu différents :

Code :

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

1
2
3
4
#ifdef sunOS
#include "/local/patch/Solaris/8_Recommended/108528-29/SUNWhea/reloc/usr/include/sys/proc.h"
#include "/usr/include/sys/cred.h"
#endif

et un peu plus loin

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
    #ifdef LINUX
    typedef struct cred {
        //   uint_t          cr_ref;       // reference count
        int          cr_ref;       // reference count
        uid_t           cr_uid;       // effective user id
        gid_t           cr_gid;       // effective group id
        uid_t           cr_ruid;      // real user id
        gid_t           cr_rgid;      // real group id
        uid_t           cr_suid;      // "saved" user id (from exec)
        } cred;
    typedef struct proc {
        //     /*
        //      * Fields requiring no explicit locking
        //      */ 
        struct  vnode *p_exec;        // pointer to a.out vnode
        struct  as *p_as;             // process adr_process space pointer
        struct  plock *p_lockp;       // ptr to proc struct's mutex lock   
        // kmutex_t p_crlock;            // lock for p_cred
        int p_crlock;    // lock for p_cred
        struct  cred    *p_cred;      // process credentials
        } proc;
    #endif
    //
    struct proc myproc, *pstproc;
    struct cred mycred, *pstcred;
 
    //
    #ifdef LINUX
        pstproc=&myproc;
        pstcred=&mycred;
        myproc.p_cred=pstcred; // ce n'est pas initialisé, mais c'est juste pour voir.
        mycred.cr_ref=1;
        mycred.cr_uid=2;
        mycred.cr_gid=3;
        mycred.cr_ruid=4;
        mycred.cr_rgid=5;
        mycred.cr_suid=6;
    #endif

Donc selon la igne qui est commentée, entre linux et sunOS, et que ceci est compilé chez moi ou au boulot, les vraies structures proc et cred de sunOS sont utilisées, ou des remplaçants bidon pour que le code tourne aussi sous linux et que je puisse essayer de le mettre au point. (avec mes faibles connaissances et votre aide qui les renforce merci)
Existe-t'il une variable d'environnement quelconque que l'on pourrait obtenir par getenv(), puis tester pour sélectionner quelle compilation faire ?
Je crois que ça existe pour choisir entre linux et windows, et qu'un même code puisse être compilé sous les deux environnements. (même si dans mon cas précis la compilation sous linux n'aurait pas le même effet sur les droits de ma shell finale, mais ça me permettrait de tester plein de code chez moi)
Merci d'avoir lu jusqu'ici ce qui se trouve être encore un bon bout de pavé,
David

[Emmanuel Delahaye]

Donc ma tête dure me pousse toujours dans la même direction, qui est :
-1°) de forker un petit programme en C,
-2°) de laisser le fils se faire tracer par le père,

Je ne sais pas trop ce que ça veut dire, mais admettons...

-3°) que le père lise l'adresse de la structure proc du fils, (pour l'instant je ne sais obtenir que l'adresse kernel, ou virtuelle, de la structure proc du fils, mais j'ai bon espoir qu'une âme généreuse me présente un moyen de convertir celle ci en adresse physique<...>

Je ne sais pas combien de fois il va falloir te répéter qu'un processus ne peut pas accéder aux données d'un autre processus par des moyens conventionnels. C'est pourtant simple à comprendre. Telle quelle (langage C) ta manip est vouée à l'échec. Point.

Il existe peut être des moyens non conventionnels qui dépendent étroitement de la machine et du système avec laquelle tu travailles, mais ce n'est pas sur un forum C que tu auras la réponse. Il faut demander à des gens hyper pointus sur ton système (et SunOS n'a rien à voir avec Linux).

Mais une petite question quand même dans ce post : comment est il possible qu'un OS se reconnaisse de lui même pour faire la compilation conditionnelle qui convient ?

Ca n'a rien à voir avec l'OS, mais avec le compilateur qui a été installé sur telle ou telle machine pour tel ou tel OS. Un compilateur est compilé pour une machine et un OS donné. Il sait donc quelle macro globale il doit définir. Si elle manque, on peut toujours l'ajouter dans la configuration du projet.

[dva2tlse]

Code :

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

un processus ne peut pas accéder aux données d'un autre processus par des moyens conventionnels

Eh bien je voudrais utiliser des moyens non conventionels, cela ne m'empêchera pas de dormir, comme ptrace qui permet à un père d'examiner des données de son fils si j'ai bien tout compris.

Ca n'a rien à voir avec l'OS, mais avec le compilateur qui a été installé sur telle ou telle machine pour tel ou tel OS

Admettons, mais je voudrais simplement savoir si un moyen existe pour que le programme sache "de lui même", ou par le biais des variables d'environnement, sur quelle machine il est en train d'être compilé.

@+

[Emmanuel Delahaye]

Code :

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

un processus ne peut pas accéder aux données d'un autre processus par des moyens conventionnels

Eh bien je voudrais utiliser des moyens non conventionels, cela ne m'empêchera pas de dormir, comme ptrace qui permet à un père d'examiner des données de son fils si j'ai bien tout compris.

Tu as l'air de dire que le code de Ptrace est 'trop fort pour toi'... C'est pourtant ce genre de méthodes non conventionnelles qu'il faut acquérir auprès des quelques gourous qui les maitrisent... Encore une fois, ce n'est pas l'objet de ce forum...

Admettons, mais je voudrais simplement savoir si un moyen existe pour que le programme sache "de lui même", ou par le biais des variables d'environnement, sur quelle machine il est en train d'être compilé.

Cette question est absurde. Un programme "en train d'être compilé" n'est pas en train de s'exécuter... Je ne comprend pas le but de la question.

C'est le compilateur qui utilise ses macros internes ou définies par l'utilisateur avec -Dmymacro). L'existence de ces macros dépend donc du compilateur utilisé à certain moment sur une certaine machine. Ca n'a rien à voir avec l'exécution. Un programme C ne peut pas savoir de façon portable sur quel système il s'exécute. Par contre, on peut créer une macro globale qui donne l'indication. Après, il faut être clair dans la gestion de ses projets. Il n'existe pas d'autorité supérieure qui attribue un code système universel connu de tous. On peut le regretter, ce serait peut être un travail à confier à l'ISO via POSIX... De toutes façons, c'est rarement utile.

[dva2tlse]

Code :

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

le but de la question

c'est que, par exemple sur la sun,

Code :

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

getenv("OSVER")-> 5.8

par exemple (s'il existe une variable d'environnement de ce nom et ayant cette valeur) et alors je peux faire un

Code :

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

#define sunOS

qui me permettra après test de compiler ce qu'il est opportun de faire.
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.