Как включить C backtrace в код модуля ядра?

Итак, я пытаюсь выяснить, какие процессы ядра вызывают некоторые функции в блочном драйвере. Я думал, что backtrace() в библиотеке C упростит работу. Но у меня возникают проблемы с загрузкой обратной линии.

Я скопировал эту примерную функцию, чтобы показать обратную трассировку:

http://www.linuxjournal.com/files/linuxjournal.com/linuxjournal/articles/063/6391/6391l1.html

Во всех попытках компиляции есть ошибка в том или ином месте, что файл не может быть найден или функции не определены.

Вот что самое близкое.

В Makefile я помещаю директивы компилятора:

 -rdynamic -I/usr/include

Если я оставлю второй, -I/usr/include, то компилятор сообщает, что не может найти требуемый заголовок execinfo.h.

Далее, в коде, где я хочу сделать backtrace, я скопировал функцию из примера:

//trying to include the c backtrace capability
#include <execinfo.h>

void show_stackframe() {
void *trace[16];
char **messages = (char **)NULL;
int i, trace_size = 0;

trace_size = backtrace(trace, 16);
messages = backtrace_symbols(trace, trace_size);
printk(KERN_ERR "[bt] Execution path:\n");
for (i=0; i<trace_size; ++i)
    printk(KERN_ERR "[bt] %s\n", messages[i]);
}
//backtrace function

Я поместил вызов этой функции позже, в функцию драйвера блока, где происходит первый признак ошибки. Просто:

show_stackframe();

Поэтому, когда я скомпилирую его, следующие ошибки:

[email protected]:~/2.6-32$ make -s
Invoking make againt the kernel at /lib/modules/2.6.32-5-686/build
In file included from /usr/include/features.h:346,
        from /usr/include/execinfo.h:22,
        from /home/linux/2.6-32/block/block26.c:49:
/usr/include/sys/cdefs.h:287:1: warning: "__always_inline" redefined
In file included from /usr/src/linux-headers-2.6.32-5-common/include/linux/compiler-gcc.h:86,
        from /usr/src/linux-headers-2.6.32-5-common/include/linux/compiler.h:40,
        from /usr/src/linux-headers-2.6.32-5-common/include/linux/stddef.h:4,
        from /usr/src/linux-headers-2.6.32-5-common/include/linux/list.h:4,
        from /usr/src/linux-headers-2.6.32-5-common/include/linux/module.h:9,
        from /home/linux/2.6-32/inc/linux_ver.h:40,
        from /home/linux/2.6-32/block/block26.c:32:
/usr/src/linux-headers-2.6.32-5-common/include/linux/compiler-gcc4.h:15:1: warning: this is the location of the previous definition
    /home/linux/2.6-32/block/block26.c:50: warning: function declaration isn’t a prototype
WARNING: "backtrace" [/home/linux/2.6-32/ndas_block.ko] undefined!
WARNING: "backtrace_symbols" [/home/linux/2.6-32/ndas_block.ko] undefined!

Примечание: block26.c - это файл, в который я надеюсь получить обратную трассировку.

Есть ли очевидная причина, по которой backtrace и backtrace_symbols остаются undefined, когда они скомпилированы в .KO-модули?

Я предполагаю, потому что я использую компилятор include execinfo.h, который находится на компьютере и не загружается в модуль.

Это мое необразованное предположение, если не сказать больше.

Может ли кто-нибудь предложить помощь для загрузки функций backtrace в модуле?

Спасибо, что посмотрели на этот запрос.

Я работаю над debian. Когда я вынимаю функцию и т.д., Модуль компилируется отлично и почти отлично работает.

От ndasusers

Ответ 2

Если вам нужно сохранить трассировку стека и обработать ее элементы каким-то образом, save_stack_trace() или dump_trace() также может быть вариантом. Эти функции объявляются в <linux/stacktrace.h> и <asm/stacktrace.h> соответственно.

Не так просто использовать их как dump_stack(), но если вам нужна большая гибкость, они могут быть полезны.

Вот как можно использовать save_stack_trace() (замените HOW_MANY_ENTRIES_TO_STORE на значение, соответствующее вашим потребностям, 16-32 обычно более чем достаточно):

unsigned long stack_entries[HOW_MANY_ENTRIES_TO_STORE];
struct stack_trace trace = {
    .nr_entries = 0,
    .entries = &stack_entries[0],

    .max_entries = HOW_MANY_ENTRIES_TO_STORE,

    /* How many "lower entries" to skip. */
    .skip = 0
}; 
save_stack_trace(&trace);

Теперь массив stack_entries содержит соответствующие адреса вызовов. Количество заполненных элементов nr_entries.

Еще одно замечание. Если желательно не выводить записи стека, которые принадлежат реализации save_stack_trace(), dump_trace() или dump_stack() сами (в разных системах количество таких записей может изменяться), следующий трюк может быть применен, если вы используйте save_stack_trace(). Вы можете использовать __builtin_return_address(0) как запись "привязки" и обрабатывать только записи "не ниже".

Ответ 1

Ответ 2