Как ускорить запуск Firefox в GDB

Question

У меня есть большое количество HTML файлов для отладки. Я написал сценарий python GDB и вызвал gdb ./path/to/firefox и открыл каждый из HTML файлов в Firefox, затем запустил сценарий, чтобы сделать то, что я хочу. Проблема в том, что этот процесс очень медленный. Мне интересно, есть ли более быстрый способ сделать это.

Я заметил, что все остальное довольно быстро, кроме точки после того, как GDB выводит следующее:

$ gdb ../firefox-63.0.3/objdir-ff-dbg/dist/bin/firefox
GNU gdb (Ubuntu 8.1-0ubuntu3.2) 8.1.0.20180409-git
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ../firefox-63.0.3/objdir-ff-dbg/dist/bin/firefox...done.
(gdb) set args file:///home/ug16zy2/test.html 
(gdb) r
Starting program: /home/ug16zy2/firefox-63.0.3/objdir-ff-dbg/dist/bin/firefox file:///home/ug16zy2/test.html 
warning: Error disabling address space randomization: Operation not permitted
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Тогда мне нужно ждать долгое время (около 20 секунд), пока он не выведет следующую строку:

Loading JavaScript value pretty-printers; see js/src/gdb/README.
If they cause trouble, type: disable pretty-printer .* SpiderMonkey
SpiderMonkey unwinder is disabled by default, to enable it type:
    enable unwinder .* SpiderMonkey

Что делает GDB и как мне избежать того, что занимает такое много времени?

PS: I Мне нужно использовать GDB, потому что я хочу остановить процесс при выполнении указанной строки c в коде JS. К сожалению, линия находится внутри обратного вызова, зарегистрированного с помощью прослушивателя событий. Проблема сводится к остановке Firefox, когда срабатывает прослушиватель событий И его функция обратного вызова завершает выполнение. (Если есть какая-либо другая альтернатива, которая может достичь того же, пожалуйста, дайте мне знать :) Большое спасибо!)

Answer 1

Как говорится в другом ответе, проблема в том, что GDB наивен в отношении кэширования debuginfo. И, поскольку libxul настолько велик, это занимает заметное количество времени.

Если у вас есть gdb 8.3 или новее, вы можете исправить это с помощью новой функции index-cache. Чтобы использовать его, просто наберите:

(gdb) set index-cache on

... или поместите его в ~/.gdbinit для лучшего эффекта.

Кэш индекса запишет индекс для debuginfo в файл в каталог кэша (введите show index-cache directory, чтобы увидеть, где). Это должно ускорить повторное чтение.

Обратите внимание, что сейчас ничто не сокращает кэш индекса - это главный недостаток. Таким образом, вы можете иногда удалять старые файлы здесь. Это отсутствие сокращения является одной из причин того, что кэш не включен по умолчанию.

Answer 2

Что делает GDB и как мне избежать того, что занимает столько времени?

Здесь происходит несколько вещей:

1. GDB считывает отладочную информацию для двоичного файла firefox, а затем запускает его.
2. Когда firefox загружает совместно используемые библиотеки, загрузчик dynamici c уведомляет GDB о них, а GDB считывает информацию об отладке для них.
3. Когда загружено libpthread, GDB загружает libthread_db и устанавливает его для уведомления GDB о событиях создания и уничтожения потока (это когда печатается сообщение Using host libthread_db).
4. firefox инициализируется.
5. firefox начинает работать (выполняет полезную работу).

Вы можете увидеть больше действий GDB с set verbose on.

I Я догадываюсь , что firefox бинарный файл напрямую связан только с несколькими общими библиотеками и dlopen с большинством необходимых библиотек после того, как он запустится (т.е. во время шага 4 выше) .

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

Если после set verbose on вы видите, что приведенные выше догадки верны, вы можете отключить автоматическую загрузку символов для разделяемых библиотек с помощью set auto-solib-add off. Затем вы можете добавить просто библиотеки, для которых вам нужны символы (если есть) с помощью команды sharedlibrary libfoo.

Обновление:

Это на самом деле занимает большую часть времени загрузки символа из libxul.so. Однако, я думаю, мне это нужно для отладки Firefox. Есть ли способ предварительной загрузки этих символов или избегания загрузки этой библиотеки каждый раз?

Я подумал, что это поможет вывернуть ваш скрипт "наизнанку" - запустить один сеанс GDB и выполнить повторное выполнение run команды с различными аргументами изнутри этого сеанса.

Но я не уверен, что это действительно поможет: в прошлый раз, когда я работал над GDB, он отбрасывал и перечитывал все DSO на подчиненном (будучи отлаженным) перезапуск программы.

Если GDB все еще делает это, единственное решение, которое я могу придумать, это:

1. Попробуйте вместо этого использовать LLDB. Это может быть быстрее или может работать со скриптом «наизнанку».
2. Сборка libxul.so с меньшим количеством отладочной информации (т. Е. Добавьте -g только для файлов, которые вам нужны для отладку и соберите остальные файлы с помощью -g0).