Discussion :

[- Robby -]

J'utilise VC++ (dans Visual Studio .net 2003). Dans la doc en ligne, il est bien spécifié que VC++ supporte, en assembleur en ligne, toutes les instructions du Pentium ... et pourtant ... "Sysenter" est refusé. Sur le même PC et sous l'assembleur en ligne de Delphi, cette instruction "passe" sans soucis ... mais j'ai quitté Delphi, c'est VC++ maintenant. Peut être une option du compilateur, j'ai cherché, mais n'ai pas trouvé. En tout cas, si l'asm inline sous Visual Studio C++, refuse l'instruction "Sysenter" ... c'est un foutu bide !
Si y'a des idées sur le sujet, elles sont les bien venues

[mat.M]

J'utilise VC++ (dans Visual Studio .net 2003). Dans la doc en ligne, il est bien spécifié que VC++ supporte, en assembleur en ligne, toutes les instructions du Pentium ... et pourtant ... "Sysenter" est refusé. Sur le même PC et sous l'assembleur en ligne de Delphi, cette instruction "passe" sans soucis ... mais j'ai quitté Delphi, c'est VC++ maintenant. Peut être une option du compilateur, j'ai cherché, mais n'ai pas trouvé. En tout cas, si l'asm inline sous Visual Studio C++, refuse l'instruction "Sysenter" ... c'est un foutu bide !
Si y'a des idées sur le sujet, elles sont les bien venues

Je ne connais pas cette instruction _asm apparemment c'est pour accéder au ring 0.
Mais si Delphi le permet rien ne prouve que cela soit une instruction stable.
Et c'est pour cela que VC++ l'interdit.

Sinon il faut peut-être utiliser des directives de précompilation comme #ifdef __Pentium || _i586 , quelque chose dans ce genre.....

[- Robby -]

Merci mat.M ... c'est courageux de m'avoir répondu
C'est une instruction du jeu d'instruction du processeur, au même titre que "mov eax, ebx" ... oui, elle est beaucoup moins connue. Ce qui est curieux, c'est que si je la code manuellement en plaçant les codes hexa correspondants ... si je place un point d'arrêt ... le debugger me "décode" bien un "sysenter". Par contre à la compilation, il refuse ... et m'indique ... Error 2400, erreur d'opcode, trouvé "newline" ... newline ??? ...
Sympa de m'avoir répondu ...

[Neitsa]

Hello Robby


Oui, VC++ (même 2005) refuse d'inliner certaines instructions...

Quand VC++ refuse d'inliner, je me fais moi-même ma tambouille...

// edité, la solution est donnée par Robby en dessous

Enfin si ca se trouve, il y a vraiment possibilité d'inliner ces instructions qu'apparament VC refuse (type : SYSENTER, SYSEXIT, UD1, UD2, SALC, RDPMC, etc.) mais je ne le connais pas...

[- Robby -]

Merci Neitsa ... sympa !
Trop tard, j'analyse tout ça demain.

PS:
ou ....

Code :

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

1
2
3
4
5
6
7
8
9
 
#define Sys_enter  __asm _emit 0fh  __asm  _emit 34h
...
__asm
{
...
Sys_enter
...
}

Je reprends ton message et tes infos demain, promis.
Bonne nuit à toi.

[Neitsa]

Argh !

Tu peux oublier tout ce que j'ai écrit... __emit est bien ce qu'il faut dans ce cas là, je l'avais complètement oublié celui-là, pourtant je m'en suis déjà servi... Ca doit d'ailleurs être expressément pour les instructions que le compilo ne sait pas inliner.

Et c'est beaucoup plus simple comme ca !

[- Robby -]

Hello Neitsa.
Mais ... fallait pas enlever ton code comme ça ... du code s'est toujours intéressant ...
Je trouve hallucinant qu'un compilo comme celui de VC++ refuse l'instruction "Sysenter" .... c'est fou ... d'autant que si tu forces le codage manuellement, et que tu vas voir via le debugger (du dit VC++) ... le "Sysenter" est reconnu !!! Oui Neitsa, il y a peut être une "option" du compilateur qui nous échappe ... mais si cette instruction n'est réellement pas reconnue ... c'est une farce monumentale ! A part ça, M$ indique bien dans la doc (du dit VC++) que pour l'asm en ligne, "toutes" les instructions du Pentium sont reconnues ... ahah ! Ceci dit Neitsa ... j'ai tappé un "sysenter" dans mon driver ... et le compilo du ddk refuse également (mais bon, le ddk, c'est aussi M$) ... avec le même message d'erreur : "2400 - Erreur d'opcode - trouvé newline". Je n'ai trouvé aucune info sur ce "trouvé newline".
Je laisse le sujet encore un moment avant d'afficher "résolu" ...
Si quelqu'un sait quelque chose, il est le bien venu.

[- Robby -]

Je viens de poser la question par internet directement au support technique de Microsoft France. Je vous tiens au courant.

[mat.M]

L'assembleur en ligne est la pour faire des petites optimisations.

Pour reellement introduire du code assembleur il vaut mieux "compiler" avec un langage assembleur comme TASM ou MASM pour avoir un fichier .obj et le lier a l'executable.

[- Robby -]

Je respecte infiniment ton avis mat.M ... quelque part, je suis d'accord avec toi. Mais ... rien n'interdit de placer autant de code assembleur en ligne que tu veux. Ceci dit ... sur un plan purement intellectuel et de pensée ... oui ... l'assembleur en ligne, dans un langage de haut niveau, n'est pas fait pour "faire" de l'assembleur ... Ma recherche concernant "Sysenter" est autre ... Je cherche à exécuter une de mes fonctions "user" en mode kernel, via une table de services systeme n°2 construite au départ de mon driver ... et via un syscall (sysenter) depuis le user. J'ai déjà réussi cela en utilisant mon dit driver, DeviceIoControl et un CallBack. Mais l'utilisation d'une table de services perso et d'un Sysenter ... ça m'amuse pas mal aussi.

[- Robby -]

J'ai donc "posé" le soucis au support technique de Microsoft France. L'échange a été établi et un ingénieur du support technique a été délégué à ma demande de support. Celui-ci a "testé" le soucis posé par l'instruction "sysenter" et reconnait ... 1) que le soucis existe en effet (dans VS.Net 2003, mais aussi dans le 2005) 2) qu'il s'agit d'un défaut du produit (il a lui même utilisé le terme de "défaut") ... la doc du produit spécifiant bien que tous les opcodes du pentium sont acceptés par l'asm en ligne de VS.Net 2003. A noter que "sysenter" n'est pas la seule instruction refusée, il y en a d'autres. Cet ingénieur microsoft me signale qu'il transmet "ce soucis" à son "groupe produit". Il me tiendra au courant bien entendu, et je ferai de même sur le forum.

[Aurelien.Regat-Barrel]

sysenter c'est pentium II non ?

[- Robby -]

Sysenter c'est "depuis" le P2 (et la suite) ... cette instruction est fondamentale ... toutes les fonctions exportées par NtOskrnl sont appelées via cette instruction sous Xp et suivants. Avant le systeme utilisait un " INT 2E" ... maintenant c'est Sysenter. Sysenter est programmé par le système (registres MSR du processeur) et permet 1) le passage en ring0 2) d'atteindre la routine " KiDispatchService ". Cette routine dispatche les demandes suivant une table d'adresses "KiServiceTable". Il y a en fait plusieurs tables. Les fonctions de NtOskrnl, c'est la table n°0, Win32K.sys la table n°1 Ces différentes tables sont gérées par une "table des tables"... " KeServiceDescriptorTable ". Voila, pour donner deux mots d'explications.

[Aurelien.Regat-Barrel]

sysenter c'est avec les procs Intel seulement. Pour AMD c'est syscall, et même sous XP ça peut être int 2E si le processeur est ancien.
http://www.codeguru.com/Cpp/W-P/system/devicedriverdevelopment/article.php/c8223/
Ma question c'est par rapport au fait que

M$ indique bien dans la doc (du dit VC++) que pour l'asm en ligne, "toutes" les instructions du Pentium sont reconnues

et que Pentium, c'est pas Pentium II

[- Robby -]

Après avoir reçu, délicatement bien entendu ... certains avis sur cette recherche concernant Sysenter ... recherche, habilement et délicatement pointée comme étant inutile et désuète, digne de l'aiguille dans le foin ... je préfère me ralier à la majorité, préférant de loin la sérenité à l'opposition, même si cette dernière est délicate et "fleurie". Personnellement, je ne suis pas tenu de produire et de rentabiliser quoi que ce soit ... ce qui me permet de creuser plus loin que les limites communément admises du bon sens. Mais si cela irrite certains, même minoritaires ... alors, laissons donc cela ... par simple sagesse. Continuons d'acheter des produits, plus ou moins parfait, et disons nous que ... bah ... ça tourne quand même pas trop mal. Je pense que le sujet est donc résolu. Merci a toux ceux qui y ont participé.