Редактировать: Я, кажется, ошибся, обратная трассировка прекрасно работает из любой точки Linux - только при удаленной отладке с gdb в ubuntu на удаленные окна, трассировка стека полностью уничтожается после входа в одну из памяти функции выделения в msvcrt ... dammit microsoft.
И это происходит как для 64-битных, так и для 32-битных окон, поэтому я не уверен, что это связано с информацией о раскрутке ...
Редактировать: Похоже, добавление -g3 и -Og помогло решить часть проблемы в некоторых программах, но проблема все еще сохраняется в других программах, не могу опубликовать их источник здесь, так как это IP моей компании - извините !
Фон
Я использую gcc для компиляции ubuntu-> ubuntu и mingw для компиляции ubuntu-> windows.
Я создал кросс-платформенную (linux + windows) библиотеку для отслеживания памяти и обнаружения утечек, которая перехватывает malloc / calloc / realloc / free с помощью байт-патча сборки на первых инструкциях (не перехватывает IAT / PLT).
Хук перенаправляет на гейт, который проверяет, включены ли хуки в текущем потоке, и перенаправляет на функцию хуков отслеживания памяти, если они есть, в противном случае он просто перенаправляет на батут реальной функции, если они отключены для этого потока. .
Библиотека прекрасно работает и обнаруживает утечки в linux / windows (возможно, будет работать на Mac, но у меня ее нет).
Я использую библиотеку для программного обнаружения утечек из моего кода, я могу устанавливать обратные вызовы в подпрограммах выделения памяти и программно поднимать точки останова (путем зацикливания и ожидания присоединения отладчика, затем выполняя asm ("int3")) внутри обратных вызовов так что я могу подключиться к моей программе, пока она находится внутри вызова, что приводит к утечке памяти.
Все прекрасно работает до тех пор, пока я не попытаюсь просмотреть обратную трассировку внутри моего обратного вызова, я понимаю, что это, вероятно, потому, что информация о раскрутке, вероятно, больше не соответствует моему стеку, потому что я вставил новые кадры и данные через подпрограммы ловушек, которые у меня есть вставлена.
Редактировать: Если я ошибаюсь из-за того, что информация о раскрутке, не совпадающая со стеком, является причиной неправильной трассировки, пожалуйста, исправьте меня!
Вопрос
Есть ли какие-нибудь небольшие хаки, которые я могу сделать, чтобы обмануть GDB в правильной перестройке обратной трассировки из моих обратных вызовов хука?
Я понимаю, что могу вручную ходить и редактировать информацию о раскрутке с помощью libdwarf или чего-то еще, но я думаю, что это было бы невероятно громоздким и большим.
Так что мне интересно, может быть, есть какой-нибудь хак или чит, который я мог бы сделать, чтобы обмануть GDB в правильном восстановлении следа?
Если нет легких хитростей или уловок, то каковы все мои варианты решения этой проблемы?
Редактировать: просто чтобы выяснить точный порядок вызовов всего:
program
V
malloc
V
hook_malloc -> hooks are disabled -> return malloc trampoline -> real malloc > program
V
hooks are enabled
V
Call original malloc -> malloc trampoline -> real malloc -> returns to hook
V
Record memory size/info etc from malloc
V
Call user defined callback -> **User defined callback* -> returns to hook
V
return to program
Это «Определяемый пользователем обратный вызов», где я хочу получить обратную трассировку