LINUX.ORG.RU

linux kernel debugging gdb

 , ,


0

2

Здравствуйте. В общем, есть задача, отладить код в ядре, использую вот это руководство:

https://www.opensourceforu.com/2011/01/understanding-a-kernel-oops/

все делаю по руководству, когда вбиваю

(gdb) list *0x00000000000781cc

ничего не выводит, вбиваю

(gdb) list*(rtw_lps_state_chk+0x34)

молчание.

вбиваю:

(gdb) list /home/user/rtl8821ce/hal/hal_com.c:rtw_lps_state_chk+0x34

выдает:

No source file named /home/user/rtl8821ce/hal/hal_com.c.

подскажите, почему gdb не видит файл исходного кода, он есть, ошибок в пути нет

# ll /home/user/rtl8821ce/hal/hal_com.c
-rw-r--r-- 1 user user 406K Nov 16  2020 /home/user/rtl8821ce/hal/hal_com.c
★★★

все делаю по руководству, когда вбиваю
(gdb) list *0x00000000000781cc

А что перед этим делаешь и какой результат команд? Судя по симптомам у тебя нет отладочных символов.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

все как по инструкции

$ gdb 8821ce.ko
# cat /sys/module/8821ce/sections/.init.text
0xffffffffc0af1000
(gdb) add-symbol-file 8821ce.ko 0xffffffffc0af1000
add symbol table from file "8821ce.ko" at
	.text_addr = 0xffffffffc0af1000
(y or n) y
Reading symbols from 8821ce.ko...done.
(gdb) 

(gdb) disassemble rtw_lps_state_chk
Dump of assembler code for function rtw_lps_state_chk:
   0x0000000000078198 <+0>:	callq  0x7819d <rtw_lps_state_chk+5>
   0x000000000007819d <+5>:	test   %sil,%sil
   0x00000000000781a0 <+8>:	jne    0x781d1 <rtw_lps_state_chk+57>
   0x00000000000781a2 <+10>:	push   %rbp
   0x00000000000781a3 <+11>:	push   %rbx
   0x00000000000781a4 <+12>:	mov    %rdi,%rbp
   0x00000000000781a7 <+15>:	mov    $0xb,%ebx
   0x00000000000781ac <+20>:	mov    $0x604,%esi
   0x00000000000781b1 <+25>:	mov    %rbp,%rdi
   0x00000000000781b4 <+28>:	callq  0x781b9 <rtw_lps_state_chk+33>
   0x00000000000781b9 <+33>:	test   %al,%al
   0x00000000000781bb <+35>:	jns    0x781ce <rtw_lps_state_chk+54>
   0x00000000000781bd <+37>:	mov    $0x1,%edi
   0x00000000000781c2 <+42>:	callq  0x781c7 <rtw_lps_state_chk+47>
   0x00000000000781c7 <+47>:	sub    $0x1,%bl
   0x00000000000781ca <+50>:	jne    0x781ac <rtw_lps_state_chk+20>
   0x00000000000781cc <+52>:	ud2    
   0x00000000000781ce <+54>:	pop    %rbx
   0x00000000000781cf <+55>:	pop    %rbp
   0x00000000000781d0 <+56>:	retq   
   0x00000000000781d1 <+57>:	retq   
End of assembler dump.
(gdb) 

далее:

(gdb) list (беру смещение из предыдущей команды (disassemble rtw_lps_state_chk) и прибавляю к нему смещение из dmesg [16880.705670] RIP: 0010:rtw_lps_state_chk+0x34/0x3a [8821ce] (0x34) получается
(gdb) list *0x00000000000781cc
(gdb)
и эта комманда молчит, пробую (прочитал в help list в gdb)
(gdb) list /home/user/rtl8821ce/hal/hal_com.c:rtw_lps_state_chk
пишет:
No source file named /home/user/rtl8821ce/hal/hal_com.c.

IvanR ★★★
() автор топика
Ответ на: комментарий от byko3y

ядро собрано с:

# grep CONFIG_DEBUG_INFO /boot/config-5.10.0-0.bpo.5-amd64 
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
# CONFIG_DEBUG_INFO_COMPRESSED is not set
# CONFIG_DEBUG_INFO_SPLIT is not set
# CONFIG_DEBUG_INFO_DWARF4 is not set
CONFIG_DEBUG_INFO_BTF=y
модуль 8821ce собирал отдельно, в ядре почему-то нет до сих пор драйвера для моей карты.

IvanR ★★★
() автор топика
Ответ на: комментарий от byko3y

делал тестовый модуль, как в руководстве, разыменовывающий нулевой указатель, все работает и находит файл исходного кода.

IvanR ★★★
() автор топика
Ответ на: комментарий от byko3y
(gdb) add-symbol-file 8821ce.ko 0xffffffffc0af1000
add symbol table from file "8821ce.ko" at
	.text_addr = 0xffffffffc0af1000
(y or n) y
Reading symbols from 8821ce.ko...done.
(gdb) info line rtw_lps_state_chk
No line number information available for address 
  0xffffffffc0b69148 <rtw_lps_state_chk>
No line number information available for address 0x78198 <rtw_lps_state_chk>
(gdb) q

без "(gdb) add-symbol-file 8821ce.ko 0xffffffffc0af1000"

(gdb) info line rtw_lps_state_chk
No line number information available for address 0x78198 <rtw_lps_state_chk>
(gdb)
отладочные символы присутствуют в модуле:
$ objdump --syms ./8821ce.ko | grep debug
0000000000000000 l    d  .debug_info	0000000000000000 .debug_info
0000000000000000 l    d  .debug_abbrev	0000000000000000 .debug_abbrev
0000000000000000 l    d  .debug_aranges	0000000000000000 .debug_aranges
0000000000000000 l    d  .debug_line	0000000000000000 .debug_line
0000000000000000 l    d  .debug_str	0000000000000000 .debug_str
0000000000000000 l    df *ABS*	0000000000000000 rtw_debug.c
0000000000097f22 l     F .text	000000000000013d _debug_dlfw_fail
0000000000000000 l    df *ABS*	0000000000000000 phydm_debug.c
0000000000000000 l    df *ABS*	0000000000000000 halrf_debug.c
00000000000bba93 g     F .text	000000000000025a phydm_dig_debug
00000000000c607d g     F .text	00000000000002f3 halrf_support_ability_debug
00000000000bbe62 g     F .text	0000000000000183 phydm_h2C_debug
00000000000c5cf9 g     F .text	000000000000009b halrf_iqk_debug
00000000000c4904 g     F .text	00000000000002b7 phydm_csi_debug
00000000000bdda7 g     F .text	000000000000036d phydm_adaptivity_debug
00000000000b34d2 g     F .text	0000000000000b85 phydm_debug_trace
00000000000c4640 g     F .text	00000000000002c4 phydm_nbi_debug
00000000000c772a g     F .text	0000000000000010 halrf_init_debug_setting
00000000000bc058 g     F .text	0000000000000301 phydm_ra_debug
00000000000b1999 g     F .text	0000000000000037 phydm_init_debug_setting
000000000000cd1a g     F .text	0000000000000042 proc_get_trx_info_debug
00000000000a01f6 g     F .text	0000000000000459 mac_debug_88xx
00000000000c2f63 g     F .text	00000000000002aa phydm_psd_debug
00000000000b4057 g     F .text	00000000000003c7 phydm_fw_debug_trace
00000000000d2cbd g     F .text	0000000000000365 _phy_iqk_debug_inner_lpbk_psd_8821c
00000000000c7026 g     F .text	0000000000000406 halrf_debug_trace

IvanR ★★★
() автор топика
Последнее исправление: IvanR (всего исправлений: 1)
Ответ на: комментарий от IvanR

Почему-то gdb не может прочитать полностью отладочную инфу. Очень странно. То ли gdb старый, то ли какие-то странные опции компиляции у модуля были, которые плохо совместимы с этим gdb. Я бы попробовал посмотреть «maint info psymtabs hal_com» и «maint info symtabs hal_com», но я делаю ставку, что оно, опять-таки, ничего не выдаст, потому что отладочную инфу gdb почему-то не читает.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

молчит проклятый:

(gdb) add-symbol-file 8821ce.ko 0xffffffffc0af1000
add symbol table from file "8821ce.ko" at
	.text_addr = 0xffffffffc0af1000
(y or n) y
Reading symbols from 8821ce.ko...done.
(gdb) maint info psymtabs hal_com
(gdb) maint info symtabs hal_com
(gdb) 
gdb из стабильной ветки debian

IvanR ★★★
() автор топика
Последнее исправление: IvanR (всего исправлений: 1)
Ответ на: комментарий от IvanR

Можешь попробовать еще потыкать какие-нибудь команды по символам:

http://sourceware.org/gdb/onlinedocs/gdb/Symbols.html

Например «info sources». Но, в любом случае, я не могу никак понять, почему gdb пишет, что символы загрузил, а в действительности не загрузил.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

пробую поставить gdb из unstable

IvanR ★★★
() автор топика
Ответ на: комментарий от byko3y

поставил другую версию gdb, странная фигня, почему-то он не видит файлов с исходным кодом

(gdb) pwd
Working directory /home/user/rtl8821ce.
(gdb) list ./hal/hal_co (tab tab)
hal_com_config_channel_plan  hal_config_macaddr
(gdb) list ./hal/hal_co
# ll /user/rtl8821ce/hal/hal_co*
-rw-r--r-- 1 user user 406K Nov 16  2020 /home/user/rtl8821ce/hal/hal_com.c
-rw-r--r-- 1 user user 4.2K Nov 16  2020 /home/user/rtl8821ce/hal/hal_com_c2h.h
-rw-r--r-- 1 user user 1.1M Jul  4 11:30 /home/user/rtl8821ce/hal/hal_com.o
-rw-r--r-- 1 user user 158K Nov 16  2020 /home/user/rtl8821ce/hal/hal_com_phycfg.c
-rw-r--r-- 1 user user 1.1M Jul  4 11:30 /home/user/rtl8821ce/hal/hal_com_phycfg.o

а те, что видит, не имеются в системе, может он их смотрит в отладочной информации модуля?

# ll /home/user/rtl8821ce/hal/hal_com_config_channel_plan
ls: cannot access '/home/user/rtl8821ce/hal/hal_com_config_channel_plan': No such file or directory
# ll /home/user/rtl8821ce/hal/hal_config_macaddr
ls: cannot access '/home/user/rtl8821ce/hal/hal_config_macaddr': No such file or directory

IvanR ★★★
() автор топика
Ответ на: комментарий от byko3y
(gdb) info sources
Source files for which symbols have been read in:



Source files for which symbols will be read in on demand:

/home/user/rtl8821ce/8821ce.mod.c
(gdb)
IvanR ★★★
() автор топика
Ответ на: комментарий от IvanR

поставил другую версию gdb, странная фигня, почему-то он не видит файлов с исходным кодом
те, что видит, не имеются в системе, может он их смотрит в отладочной информации модуля?

Да, gdb главным образом руководствуется именно отладочной инфой, и ошибка «файл не найден» — это значит «не найден в отладочных символах». Хз, что там за сборочный конвеер такой у твоего модуля. Может, там все сорцы сваливаются в единый сишный модуль? Или какой-то кастомный линковщик используется.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

еще один вопрос: вот этот адрес

cat /sys/module/8821ce/sections/.init.text
0xffffffffc0af1000
динамический, то есть на разных системах он будет разный или этот адрес захардкожен в модуль линковщиком? я думаю, что код модуля должен быть position independent и ядро загружает модуль в произвольную область памяти, следовательно еще один вопрос: у меня сбой в модуле происходит на другой железке, обязательно нужно вводить вот эту команду
add-symbol-file 8821ce.ko 0xffffffffc0af1000
с этим адресом или можно что-то произвольное подставлять?

IvanR ★★★
() автор топика
Ответ на: комментарий от IvanR

вот этот адрес динамический, то есть на разных системах он будет разный или этот адрес захардкожен в модуль линковщиком?

По разному, можешь перепроверить через

cat /sys/module/8821ce/sections/.text

но на загрузку отладочной инфы это не влияет.

byko3y ★★★★
()
Ответ на: комментарий от byko3y

раз уж такая пьянка, позволю себе задать вопрос, можно ли так собрать gdb, чтобы он работал на хостовой машине x86-64, а отлаживал бинарники для arm? подозреваю, что нет :) но все-таки спросил.

Видимо надо использовать gdb сервер на железке с arm а на хосте использовать версию для x86-64&

anonymous
()
Ответ на: комментарий от anonymous

можно ли так собрать gdb, чтобы он работал на хостовой машине x86-64, а отлаживал бинарники для arm? подозреваю, что нет

Да, ты правильно понял — только сервер. Нужно как-то выполнять машинный код на целевой архитектуре процессора, что позволяет делать, например, Win API через Read/WriteProcessMemory и CreateRemoteThread, но в посиксах для этого нет совсем никаких API, можно только раскручиваться изнутри уже работающего целевого процесса.

byko3y ★★★★
()
Ответ на: комментарий от imb

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

IvanR ★★★
() автор топика
Ответ на: комментарий от IvanR

В таком случае может воспользоваться командой addr2line (часть binutils), если она распарсит отладочную информацию?

xaizek ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.