Я использую gdb 7.4.1 для встроенной цели powerpc, чтобы выполнить некоторый анализ моей многопоточной программы C ++, которая использует pthreads. Моя конечная цель - создать скрипт gdb с python для автоматизации некоторых общих функций анализа. Проблема в том, что я нахожу некоторое несоответствие в поведении, когда я запускаю команды индивидуально, а не в пользовательской команде GDB (или вызываю те же команды через скрипт Python).

редактировать: я нашелэтот ссылка на очень похожую проблему в основном списке рассылки GDB. Хотя я не полностью следую ответу Педро об ограничении асинхронного режима, я думаю, он подразумевает, что в асинхронном режиме относительная синхронизация определенных пользователем последовательностей команд не может быть доверенной. Это то, что я нашел опытным путем.

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

(gdb) file myprogram
(gdb) set args --interface=eth0 --try-count=0
(gdb) set target-async on
(gdb) set pagination off
(gdb) set non-stop on
(gdb) run &

На данный момент, если я вручную выдатьinterrupt а потомinfo threads команды, я вижу список всех запущенных потоков, кроме одного, который был остановлен. Тогда я могуcontinue & и, повторяю, к сердцу содержание, он работает последовательно. Когда он остановлен, я могу проверить кадры стека этого потока, и все в порядке.

Однако, если вместо этого я помещу эти команды в пользовательскую команду GDB:

(gdb) define foo
(gdb) interrupt
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

Затем список потоков, напечатанный foo, указывает, что ни один поток не был остановлен, и поэтомуcontinue & команда возвращаетсяCannot execute this command while the selected thread is running., Я подумал, что это проблема, присущая асинхронному командованию GDB, поэтому я вставил нелепо долгое ожидание после команды прерывания и получил такое же поведение:

(gdb) define foo
(gdb) interrupt
(gdb) shell sleep 5
(gdb) info threads
(gdb) continue &
(gdb) end
(gdb) foo
Cannot execute this command while the selected thread is running.

С или без команды сна, я всегда могу выполнить ручные команды CLI, и потоки останавливаются правильно.

Точно так же я получаю те же результаты, что и скрипт python для просмотра потока:

import gdb, time

gdb.execute("file myprogram")
gdb.execute("set args --interface=eth0 --try-count=0")
gdb.execute("set target-async on")
gdb.execute("set pagination off") 
gdb.execute("set non-stop on")
gdb.execute("run &")
time.sleep(5)
gdb.execute("interrupt")

# here, I inspect threads via gdb module interface
# in practice, they're always all running bc the program neven got interrupted
for thread in gdb.selected_inferior().threads():
    print thread.is_running(),

gdb.execute("continue &")

Я получаю тот же результат, даже если я укажуfrom_tty=True вgdb.execute звонки. Кроме того, если я используюcontinue -a он подавляет строку ошибки, но не помогает, в противном случае вызов прерывания все еще не работает.

Итак ... это:

cockpit error? Is there something that I'm omitting or doing incorrectly, given what I'm trying to accomplish? Should this work, or do I have to use GDB/MI to asynchronously "drive" gdb like this? a timing problem? Maybe invoking shell sleep (or python time.sleep()) doesn't do what I assume it would, in this context. problem with my usage of pthreads? I have assumed that since using manual gdb commands always works correctly this is not the case. a gdb problem?

Благодарю.