Сценарий GDB слишком медленный, нужна помощь / предложения - PullRequest
0 голосов
/ 18 августа 2011

Я пишу сценарий GDB для анализа файла ядра. Цель которого заключается в следующем:
1] Я ищу пакеты, которые разбросаны в пространстве 64 МБ. Пакет имеет магическое число 4 байта. Следовательно, я должен читать 4 байта за раз.
2] Я должен прочитать в общей сложности 64 МБ данных, начиная с данного адреса.
3] Как только я найду пакет, я должен напечатать детали пакета и продолжить поиск других пакетов.
4] Следовательно, в моем сценарии основной цикл выполняется в худшем случае 64 *1024* 1024/4 = 16777216 раз.
В чем проблема:
Сценарий занимает около 3 часов или более, что совершенно нецелесообразно.
Я предполагаю, что это потому, что это интерпретируемый язык, а также число циклов довольно большое.
Любые предложения / улучшения приветствуются. Пожалуйста, помогите мне здесь.

Ответы [ 2 ]

2 голосов
/ 18 августа 2011

команда find должна делать все, что вы хотите, без необходимости повторять каждые 4 байта или около того, хранит адрес последнего найденного пакета в $ _ (не проверено, но должно быть что-то с эффектом)

(gdb) python x = list()
(gdb) set $start_addr = 0x....
(gdb) set $last_end = $start_addr
(gdb) set $_ = $start_addr+1
(gdb) while $_ != $last_end
 >find $last_end, $start_addr + 64*1024*1024, 0x42
 >set $last_end = $_
 >python x.append(gdb.parse_and_eval("$_"))
 >end
(gdb) python print map(lambda(y): str(y), x)

если у вас нет python, вы можете использовать перезапись набора журналов, установить регистрацию, печать, отключить регистрацию

2 голосов
/ 18 августа 2011

Если вы думаете, что проблема в том, что GDB работает медленно, вы можете сбросить интересующую вас область памяти с помощью «dump bin memory», а затем использовать небольшую программу, написанную на том, что, по вашему мнению, будет быстрее для анализа дампа.

...