Я работаю над проектом, который использует GNU Autotools, поэтому для того, чтобы отладить код с помощью GDB, я бегу GDB изнутри Libtool:с помощью Libtool е GDB
libtool --mode=execute gdbtui foobar
Можно ли перезагрузить измененная версия проекта без досады покинуть gdb/libtool и перезапустить?
Немного сложно понять, что именно вы спрашиваете, но я надеюсь, что правильно вас понял.
Да, вы можете нормально запустить отладочную команду снова с gdb, если она была начата с gdb. На самом деле это общий рабочий процесс для gdb. Используйте его в одном окне/вкладке/панели, чтобы отладить ваши вещи и исправить код в другой, восстановить в третьем и т.д.
Один путь gdb запускается это одна:
# gdb --args command arg1 arg2 ...
другой является:
# gdb command
В последнем случае вы все равно только запускаете программу из подсказки gdb, как это.
(gdb) run arg1 arg2 ...
в первом аргументы подразумеваемые (и запоминаются gdb). В любом случае вы можете получить аргументы после факта использования:
(gdb) show args
Распространено восстановить программу, как только вы нажмете, анализироваться и исправлена ошибка повторного запустить его, используя только run (который повторно предыдущие рассуждения) и проверить исправление или продолжить отладку другой проблемы.
Но когда программа построена с использованием GNU autotools, вы не можете вызывать gdb непосредственно из командной строки, как вы предлагаете.Скорее, нужно ссылаться на gdb косвенно через «libtool», как в однострочном выражении, которое я задал в моем вопросе. Именно в этом сценарии мой вопрос стоит. Для фона обратитесь к вопросу http://stackoverflow.com/questions/12148668/how-to-debug-a-program-wrapped-in-a-libtool-script – user1404316
@ user1404316: и вы попытались запустить 'show args' из в 'gdb'? И да, это возможно * запустить готовую программу вручную с помощью 'gdb'. Не уверен, что вы хотите, однако, вообще возможно. Однако вы должны добавить эти разъяснения к своему вопросу. С другой стороны, почему бы вам не отделить этап сборки и отладки/выполнения * с * 'libtool' и использовать описанный выше метод, как я описал его? В большинстве случаев во время отладки зависимостей библиотеки не будет изменяться, поэтому вам все равно будет хорошо, если вы повторно запустите процесс. – 0xC0000022L
'libtool' по умолчанию создает скрипт оболочки (который называется так же, как и двоичный), и сам двоичный файл помещается в подкаталог .libs /. Реальный двоичный файл появится только после 'make install' или при использовании' libtool -mode = execute'. См. Ответ от @Illia K. –
libtool --mode=execute создает временный исполняемый файл, который передается в gdb. Этот исполняемый файл удаляется при восстановлении. Хитрость заключается в том, чтобы воссоздать его с чем-то вроде
libtool --mode=execute echo ./hello
(Libtool воссоздаст временный исполняемый файл и передать его имя echo команды. Вы можете использовать любую другую команду вместо echo, например true подавить вывод, или даже не -existing.)
Чтобы перезагрузить исполняемый файл gdb filefilename. Исполняемые настоящее имя отображается при запуске GDB:
$ libtool --mode=execute gdb --args ./hello
...
Reading symbols from /path/to/.libs/lt-hello...done.
(gdb)
Он также отображается GdB info inferiors команды:
(gdb) info inferiors
Num Description Executable
* 1 <null> /path/to/.libs/lt-hello
и, конечно же, с помощью выше echo команды.
Для фона, когда программа построена с использованием autotools, ее нельзя отлаживать напрямую с помощью gdb. См. Например: http://stackoverflow.com/questions/12148668/how-to-debug-a-program-wrapped-in-a-libtool-script – user1404316
Windows или Unix? – Rudi