Pourquoi strace ignore-t-il certains syscalls (de façon aléatoire) selon l'environnement/le noyau ?

Question

Si je compile le programme suivant :

$ cat main.cpp && g++ main.cpp
#include <time.h>
int main() {
    struct timespec ts;
    return clock_gettime(CLOCK_MONOTONIC, &ts);
}

et ensuite l'exécuter sous strace dans Kubuntu "standard", j'obtiens ceci :

strace -tt --trace=clock_gettime ./a.out
17:58:40.395200 +++ exited with 0 +++

Comme vous pouvez le voir, il n'y a pas clock_gettime (complet strace La sortie est aquí ).

D'un autre côté, si j'exécute la même application dans mon noyau linux personnalisé sous le nom de qemu j'obtiens le résultat suivant :

strace -tt --trace=clock_gettime ./a.out
18:00:53.082115 clock_gettime(CLOCK_MONOTONIC, {tv_sec=101481, tv_nsec=107976517}) = 0
18:00:53.082331 +++ exited with 0 +++

Ce qui est le plus attendu - il y a clock_gettime .

Donc, mes questions sont :

• Pourquoi est-ce que strace ignorer/omettre clock_gettime si je l'exécute dans Kubuntu ?
• Pourquoi strace Le comportement de l'utilisateur diffère selon l'environnement/le noyau ?

Answer 1

Réponse à la première question

Desde homme vdso

strace(1), seccomp(2), et vDSO

Lors du suivi des appels système avec strace(1), les symboles (appels système) qui sont exportés par le vDSO n'apparaîtra pas dans la sortie de la trace . De même, ces appels système ne seront pas visibles par les filtres seccomp(2).

Réponse : à la deuxième question :

Dans le vDSO, clock_gettimeofday et les fonctions connexes dépendent de modes d'horloge spécifiques ; voir __arch_get_hw_counter.

Si le mode d'horloge est VCLOCK_TSC, l'heure est lue sans syscall. , en utilisant RDTSC ; si c'est VCLOCK_PVCLOCK ou VCLOCK_HVCLOCK, il est lu à partir d'une page spécifique pour récupérer les informations de l'hyperviseur. HPET ne déclare pas de mode d'horloge, il se retrouve donc avec la valeur par défaut VCLOCK_NONE, et le vDSO lance un appel système pour récupérer l'heure. .

Et en effet :

Dans le noyau par défaut (de Kubuntu) :

$ cat /sys/devices/system/clocksource/clocksource0/available_clocksource
tsc hpet acpi_pm
$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
tsc

Noyau construit sur mesure :

$ cat /sys/devices/system/clocksource/clocksource0/current_clocksource
hpet

---

Plus d'informations sur les différentes sources d'horloge. En particulier :

La documentation de Red Hat MRG version 2 indique que TSC est la source d'horloge préférée en raison de sa surcharge beaucoup plus faible, mais elle utilise HPET comme solution de secours. Un benchmark dans cet environnement pour 10 millions d'événements a montré que TSC prenait environ 0,6 seconde, HPET un peu plus de 12 secondes, et ACPI Power Management Timer environ 24 secondes.

Answer 2

Cela peut être dû au fait que clock_gettime() fait partie des syscalls optimisés. Regardez le mécanisme vdso décrit dans cet article. réponse .