systemtap: Возможность доступа к локальным переменным, но не имеет доступа к локальным указателям

Question

У меня есть немой вопрос, Я хотел понять поток исходного кода с помощью системного крана, для этого я пытался получить доступ к локальной переменной с помощью ядра. функция зондирования оператора, отображает всю другую переменную, кроме указателей.

probe module("Module_Path/proc_rw.ko").statement("my_write@Module Src Path/proc_rw.c+9") 
{ 
    printf("local = %s\n", $$locals) 
} 


Module Code : 
static ssize_t my_write(struct file *f, const char __user *buf, size_t len, loff_t *off) 
{ 
     pid_t pid; 
     int ret; 
     struct task_struct *task_local; 
     int *i;  
     ret=copy_from_user(c, buf, len); 
     i=&ret; 
     pid=simple_strtol(buf, NULL, 10); 
     task_local=pid_task(find_vpid(pid), PIDTYPE_PID); 
     return len; 
} 

Когда я исполняю выше Stap кода, он возвращается,

локальная = PID = 0xf98 RET = 0x0 task_local =? я =?

Любая помощь, чтобы понять, почему значения task_local и i не печатаются, было бы полезно.

С уважением, Yash.

Answer 1

Что вы видите здесь, это артефакт оптимизации компилятора. Переменные, которые больше не используются, могут освобождать свои ресурсы (повторное использование регистров или слотов фреймов кадров), поэтому, даже если они теоретически в области видимости, нет никакой ценности для чтения.

Вы бы увидели то же самое, если бы вы выполнили gdb на аналогичной программе и перешли на дальнюю линию, а затем попытались напечатать эти переменные. Или попробуйте:

stap -L 'module("Module_Path/proc_rw.ko").statement("my_write@*:*")' 

увидеть дамп заявлений & переменных, доступных в каждом.

Кроме того, см. https://lkml.org/lkml/2015/4/23/605 для патча ядра, целью которого было отменить недавнее нежелательное снижение качества debuginfo (2014-10). (Он не был объединен.) Но вы можете исправить его для своего собственного модуля, настроив собственный Makefile.