Bonjour à tous,
voila j'ai utilisé la commande strace et j'ai beaucoup d'interrogation sur ce programme.
je vois lorsque je fais strace ./a.out énormément d'appel systeme avant d'arriver au début de mon programme. Qui a ajouté tous ces appels systemes ? le compilateur ?
ensuite je vois :
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"…, 832) = 832
je connais les appels systemes openat et read, mais c'est quoi \177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0, une zone mémoire de mon programme a.out ?
et donc je place a cette zone mémoire que les 832 premiers octets de la libc ?
Merci d'avance pour votre aide ?
# man 2 read
Posté par liberforce (site web personnel) . Évalué à 3.
http://codewiki.wikidot.com/c:system-calls:read
Le 2ème paramètre,
buf
est le buffer où tu vas stocker les données lues. strace ne fait que t'afficher le contenu de ce buffer (après l'appel il me semble, à vérifier). Donc je dirais que la chaine que tu trouves bizarre correspond aux premiers octets de la libc que tu es en train de charger.[^] # Re: man 2 read
Posté par liberforce (site web personnel) . Évalué à 3. Dernière modification le 26 avril 2019 à 12:27.
Tu peux utiliser
od
pour le vérifier: ici je lis les 32 premiers octets du fichier en question, les caractères non-imprimables étant affichés sous leur forme en octal:La même chose en hexadécimal:
[^] # Re: man 2 read
Posté par David Marec . Évalué à 2.
Oui.
Ceux sont d'ailleurs les entêtes ELF.
# linker
Posté par David Marec . Évalué à 3.
Le linker plutôt. Dans le cas d'un programme
C
,gcc
va linker par défaut dynamiquement sur lalibc
.# derniere question
Posté par viviNeutron . Évalué à 1. Dernière modification le 29 avril 2019 à 09:20.
Merci beaucoup pour vos réponses. J'ai une derniere question, quand je fais strace ./a.out j'ai ceci qui apparait :
openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libc.so.6", O_RDONLY|O_CLOEXEC) = 3
read(3, "\177ELF\2\1\1\3\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\260\34\2\0\0\0\0\0"…, 832) = 832
fstat(3, {st_mode=S_IFREG|0755, st_size=2030544, …}) = 0
mmap(NULL, 4131552, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 0x7fb8a349b000
ce que je ne comprend pas, c'est pourquoi placer les 832 premiers octets de la libc sur un pointeur (via read) pour ensuite mettre les premiers 4Mo de la libc en RAM (via mmap)?
[^] # Re: derniere question
Posté par claudex . Évalué à 3.
https://repo.or.cz/glibc.git/blob/HEAD:/elf/dl-load.c#l34
C'est une heuristique de la libc, dans la plupart des cas, les informations utiles pour le reste du déroulement du programme sont dans les 832 bytes.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.