Exécution du code d'assemblage 32 bits sur un système Linux 64 bits & amp; Processeur 64 bits: Expliquer l'anomalie

N'oubliez pas que tout par défaut sur un système d'exploitation 64 bits a tendance à présumer de 64 bits. Vous devez vous assurer que vous êtes (a) en utilisant les versions 32 bits de votre #inclut le cas échéant (b) la liaison avec 32 bits des bibliothèques et (c) la construction d'un exécutable 32 bits. Il serait probablement aider si vous avez montré le contenu de votre makefile si vous en avez un, sinon les commandes que vous utilisez pour construire cet exemple.

FWIW j'ai changé votre code légèrement (_start -> main):

#include <asm/unistd.h>
#include <syscall.h>
#define STDOUT 1

    .data
hellostr:
    .ascii "hello wolrd\n" ;
helloend:

    .text
    .globl main

main:
    movl $(SYS_write) , %eax  //ssize_t write(int fd, const void *buf, size_t count);
    movl $(STDOUT) , %ebx
    movl $hellostr , %ecx
    movl $(helloend-hellostr) , %edx
    int $0x80

    movl $(SYS_exit), %eax //void _exit(int status);
    xorl %ebx, %ebx
    int $0x80

    ret

et l'a construit comme ceci:

$ gcc -Wall test.S -m32 -o test

verfied que nous avons un exécutable 32 bits:

$ file test
test: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.4, dynamically linked (uses shared libs), not stripped

et il semble OK:

$ ./test
hello wolrd

Cpu 64 bits peut exécuter du code 32 bits, mais ils ont à utiliser un mode spécial pour le faire. Ces instructions sont valides en mode 64 bits, donc rien ne vous a empêché de construire une 64-bit exécutable.

Votre code construit et fonctionne correctement avec gcc -m32 -nostdlib hello.S. C'est parce que -m32 définit __i386donc /usr/include/asm/unistd.h comprend <asm/unistd_32.h>qui a le droit constantes pour les int $0x80 ABI.

Voir aussi L'assemblage des binaires 32 bits sur un système 64 bits (GNU toolchain) pour en savoir plus sur _start vs main avec/sans libc et statique vs dynamique des fichiers exécutables.

$ file a.out 
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, BuildID[sha1]=973fd6a0b7fa15b2d95420c7a96e454641c31b24, not stripped

$ strace ./a.out  > /dev/null
execve("./a.out", ["./a.out"], 0x7ffd43582110 /* 64 vars */) = 0
strace: [ Process PID=2773 runs in 32 bit mode. ]
write(1, "hello wolrd\n", 12)           = 12
exit(0)                                 = ?
+++ exited with 0 +++

Techniquement, si vous aviez utilisé le droit d'appeler les numéros de votre code d'arriver à travailler de mode 64 bits ainsi: Qu'advient-il si vous utilisez la version 32 bits de type int 0x80 ABI Linux en 64 bits de code? Mais int 0x80 n'est pas recommandé dans le code 64 bits. (En fait, il n'est jamais recommandé. Pour plus d'efficacité, code 32 bits devrait appeler à travers le noyau est exporté VDSO page afin qu'il puisse utiliser sysenter rapide des appels système sur des Processeurs qui le prennent en charge).

Mais cela ne veut pas répondre à mes à mes questions. Qu'est-ce exactement est qui se passe dans ce cas?

Bonne question.

Sur Linux, int $0x80 avec eax=1 est sys_exit(ebx)quel que soit le mode le processus appelant a été en. Les 32 bits de l'ABI est disponible en mode 64 bits (à moins que votre noyau a été compilé sans i386 support de l'ABI), mais ne l'utilisez pas. Votre statut de sortie est de movl $(STDOUT), %ebx.

(BTW, il y a un STDOUT_FILENO macro définie dans unistd.hmais vous ne pouvez pas #include <unistd.h> à partir d'un .S car il contient également C prototypes qui ne sont pas valides asm syntaxe.)

Avis que __NR_exit de unistd_32.h et __NR_write de unistd_64.h sont à la fois 1de sorte que votre première int $0x80 sort de votre processus. Vous utilisez le mauvais système de numéros d'appel pour l'ABI vous êtes en invoquant.

strace est en train de décoder de manière incorrectecomme si vous aviez invoqué syscall (parce que c'est l'ABI un processus 64 bits est prévu de l'utiliser). Quelles sont les conventions d'appel pour UNIX & appels système Linux sur x86-64

eax=1 /syscall signifie write(rd=edi, buf=rsi, len=rdx)et c'est de cette façon strace est mal décodage votre int $0x80.

rdi et rsi sont 0 (aka NULL) à l'entrée de _startet votre code définit rdx=12 avec movl $(helloend-hellostr) , %edx.

Linux initialise les registres à zéro dans un nouveau processus après execve. (L'ABI dit pas défini, Linux choisit zéro pour éviter info fuites). Dans votre statiquement lié exécutable, _start est le premier utilisateur de l'espace de code qui s'exécute. (Dans une dynamique exécutable, l'éditeur de liens dynamique s'exécute avant _startet de ne laisser de déchets dans des registres).

Voir aussi le x86 la balise wiki pour plus d'asm liens.