Разрешение адресов трассировки исполняемого файла пользователя в ftrace

Я пытаюсь получить трассировку стека пользователей в ftrace , но по какой-то причине только моя пользовательская программа не может разрешить адреса для символов. Во-первых, используемая ОС:

 $ uname -a Linux mypc 2.6.38-16-generic #67-Ubuntu SMP Thu Sep 6 18:00:43 UTC 2012 i686 i686 i386 GNU/Linux 

Ниже приведена (тривиальная) программа пользовательского пространства, которую я использую, wtest.c . Я скомпилирую его с помощью:

 gcc -g -pg -O0 wtest.c -o wtest 

… надеясь, что -g и -pg будут содержать достаточную информацию об отладочной информации.

Затем я запускаю программу wtest под ftrace . Обратите внимание, что я хочу получить пользовательское пространство stacktrace как своего рода руководство, где в моей программе пользовательского пространства я в настоящее время, в то время как в противном случае я запускаю function tracer. Linux / Documentation / trace / ftrace.txt не является явным об этом, но для того, чтобы иметь трассировку стека, должно быть что-то, что могло бы вызвать его, – и просто function (или function_graph ) трассировщика сама по себе не будет выполните любой такой запуск. Поэтому я выбираю events/raw_syscalls в любое время, когда системный вызов обнаруживается через events/raw_syscalls . Кроме того, трассировка стека будет печатать только адреса, если не указан sym-userobj . Итак, я запускаю этот скрипт для отслеживания:

 sudo bash -c ' KDBGPATH="/sys/kernel/debug/tracing" echo 1 > $KDBGPATH/events/raw_syscalls/enable echo userstacktrace > $KDBGPATH/trace_options echo sym-userobj > $KDBGPATH/trace_options echo function > $KDBGPATH/current_tracer ; echo 0 > $KDBGPATH/tracing_on echo > $KDBGPATH/trace echo 1 > $KDBGPATH/tracing_on ; /media/disk/wtest ; echo 0 > $KDBGPATH/tracing_on cat $KDBGPATH/trace > wtest.ftrace ' 

Тем не менее, трассировка заканчивается тем, что выглядит следующим образом:

 ... wtest-16108 [000] 16246.413238: arch_flush_lazy_mmu_mode <-__kunmap_atomic Xorg-1136 [001] 16246.413239: syscall_trace_leave <-syscall_exit_work wtest-16108 [000] 16246.413240: up_read <-do_page_fault Xorg-1136 [001] 16246.413241: sys_exit: NR 54 = 0 Xorg-1136 [001] 16246.413242: <user stack trace> => <008f9416> => /lib/i386-linux-gnu/libdrm_intel.so.1.0.0[+0x4f49] => /lib/i386-linux-gnu/libdrm_intel.so.1.0.0[+0x5cc3] => /lib/i386-linux-gnu/libdrm_intel.so.1.0.0[+0x13a3] => /usr/lib/xorg/modules/drivers/intel_drv.so[+0xec58] => /usr/lib/xorg/modules/drivers/intel_drv.so[+0x2957a] => /usr/lib/xorg/modules/drivers/intel_drv.so[+0x2d403] => /usr/bin/Xorg[+0xdefc8] Xorg-1136 [001] 16246.413242: save_stack_trace_user <-ftrace_trace_userstack Xorg-1136 [001] 16246.413242: __copy_from_user_ll_nozero <-save_stack_trace_user Xorg-1136 [001] 16246.413242: __copy_from_user_ll_nozero <-save_stack_trace_user Xorg-1136 [001] 16246.413242: __copy_from_user_ll_nozero <-save_stack_trace_user Xorg-1136 [001] 16246.413242: __copy_from_user_ll_nozero <-save_stack_trace_user Xorg-1136 [001] 16246.413242: __copy_from_user_ll_nozero <-save_stack_trace_user Xorg-1136 [001] 16246.413242: __copy_from_user_ll_nozero <-save_stack_trace_user Xorg-1136 [001] 16246.413242: __copy_from_user_ll_nozero <-save_stack_trace_user wtest-16108 [000] 16246.413242: syscall_trace_leave <-syscall_exit_work wtest-16108 [000] 16246.413243: sys_exit: NR 120 = 0 wtest-16108 [000] 16246.413245: <user stack trace> => <00222416> => <08086a69> => <080753e0> => <080783b5> => <08073c09> => <08077c93> => <08078374> => <08073c09> wtest-16108 [000] 16246.413245: save_stack_trace_user <-ftrace_trace_userstack wtest-16108 [000] 16246.413245: __copy_from_user_ll_nozero <-save_stack_trace_user wtest-16108 [000] 16246.413245: __copy_from_user_ll_nozero <-save_stack_trace_user wtest-16108 [000] 16246.413245: __copy_from_user_ll_nozero <-save_stack_trace_user wtest-16108 [000] 16246.413245: __copy_from_user_ll_nozero <-save_stack_trace_user wtest-16108 [000] 16246.413245: __copy_from_user_ll_nozero <-save_stack_trace_user wtest-16108 [000] 16246.413245: __copy_from_user_ll_nozero <-save_stack_trace_user wtest-16108 [000] 16246.413245: __copy_from_user_ll_nozero <-save_stack_trace_user wtest-16108 [000] 16246.413260: down_read_trylock <-do_page_fault wtest-16108 [000] 16246.413262: _cond_resched <-do_page_fault wtest-16108 [000] 16246.413263: find_vma <-do_page_fault wtest-16108 [000] 16246.413265: handle_mm_fault <-do_page_fault wtest-16108 [000] 16246.413266: __kmap_atomic <-handle_mm_fault ... 

Другими словами – у Xorg трассировка пользовательского стека прекрасна (по крайней мере, в библиотеках .so ) – и почти все остальные процессы заканчиваются в журнале ftrace (например, bash и т. Д.); однако трассировка пользовательского стека для wtest печатается только с адресами?! Я явно назвал исполняемый файл его абсолютным путем, но это, похоже, не имеет большого значения.

Есть ли способ, которым я мог бы скомпилировать мою wtest программу, поэтому ее трассировка пользовательского стека получает свои символы, или проблема лежит в другом месте? (Я попробовал -ggdb и -gdwarf-2 вместо -g , но они здесь действительно не помогают …)

Вот код для wtest.c :

 #include <stdio.h> #include <fcntl.h> // O_CREAT, O_WRONLY, S_IRUSR int main(void) { char filename[] = "/tmp/wtest.txt"; char buffer[] = "abcd"; int fd; mode_t perms = S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP|S_IROTH|S_IWOTH; fd = open(filename, O_RDWR|O_CREAT, perms); write(fd,buffer,4); close(fd); return 0; } 

  • Драйвер Linux не работает должным образом, когда скомпилирован в ядро
  • Как написано ядро?
  • Какой тип файла / dev / core или / proc / kcore?
  • Хранение огромных данных в ядре Linux
  • Устройство USB 3.0, не перечисленное на порту USB 3.0 в операционной системе Debian 6.0
  • Являются ли исходные IP-адреса включенными в уникальность уникального порта Linux?
  • Ошибка при загрузке зашифрованного диска: не удается инициализировать устройство-картограф
  • Как узнать, какие алгоритмы декомпрессии скомпилированы в ядро ​​linux?
  • One Solution collect form web for “Разрешение адресов трассировки исполняемого файла пользователя в ftrace”

    Переключатель -g – это то, что позволит gcc скомпилировать ваш код с включенными символами отладки. Если вы не видите каких-либо символов, проблема, скорее всего, является библиотекой, которую вы компилируете, и не предоставляет версию библиотеки с включенными символами.

    См. Это SO Q & A: озаглавленный: Как вариант отладки -g Изменить исполняемый файл? , Этот SO Q & A также упоминает отладочные символы и символы компоновщика, озаглавленные: Почему gcc добавляет символы в не-отладочную сборку? ,

    Если вам нужны отладочные символы для конкретного пакета / библиотеки, они обычно называются <package name>-dbg или <package name>-dbgsym на Ubuntu. В этой статье обсуждалось это более подробно, озаглавленное: DebuggingProgramCrash .

    Linux и Unix - лучшая ОС в мире.