Сообщение Re[3]: Определение стека потока, который стоит на мьютексе от 03.12.2021 11:16
Изменено 03.12.2021 11:18 lpd
Re[3]: Определение стека потока, который стоит на мьютексе
Здравствуйте, Рома Мик, Вы писали:
РМ>Отдадочная информация в рантайме не используется, собираются только адреса. Отладочную информацию применяю уже потом отдельной утилитой.
Думаю можно собрать бинарники с отладочной информацией, и лучше включить frame-pointers. Но с arm/android я почти не работал.
РМ>Я в этом совсем профан и возможно скажу глупость: как вообще могут функции работать без stack-frame pointers? Процессор же должен куда-то перейти по return? В каком-то виде эта информация обязана быть. Вот её и надо извлечь.
Адрес возрата на стеке в любом случае есть. Без frame-pointerов нет адресов текущего фрейма (в rbp на x86_64), и на стек не сохраняется адрес предыдущего по call-stack фрейма(push $rbp;mov $rbp, $rsp), поэтому где именно этот адрес возврата неизвестно. Для отладки используют отладочную информацию, например в форматах DWARF или ORC — из нее можно для любой точки кода функции получить позиции на стеке адреса возрата и локальных переменных.
РМ>Отдадочная информация в рантайме не используется, собираются только адреса. Отладочную информацию применяю уже потом отдельной утилитой.
Думаю можно собрать бинарники с отладочной информацией, и лучше включить frame-pointers. Но с arm/android я почти не работал.
РМ>Я в этом совсем профан и возможно скажу глупость: как вообще могут функции работать без stack-frame pointers? Процессор же должен куда-то перейти по return? В каком-то виде эта информация обязана быть. Вот её и надо извлечь.
Адрес возрата на стеке в любом случае есть. Без frame-pointerов нет адресов текущего фрейма (в rbp на x86_64), и на стек не сохраняется адрес предыдущего по call-stack фрейма(push $rbp;mov $rbp, $rsp), поэтому где именно этот адрес возврата неизвестно. Для отладки используют отладочную информацию, например в форматах DWARF или ORC — из нее можно для любой точки кода функции получить позиции на стеке адреса возрата и локальных переменных.
Re[3]: Определение стека потока, который стоит на мьютексе
Здравствуйте, Рома Мик, Вы писали:
РМ>Отдадочная информация в рантайме не используется, собираются только адреса. Отладочную информацию применяю уже потом отдельной утилитой.
Думаю можно собрать бинарники с отладочной информацией, и лучше включить frame-pointers. Но с arm/android я почти не работал.
РМ>Я в этом совсем профан и возможно скажу глупость: как вообще могут функции работать без stack-frame pointers? Процессор же должен куда-то перейти по return? В каком-то виде эта информация обязана быть. Вот её и надо извлечь.
Адрес возрата на стеке в любом случае есть. Без frame-pointerов нет адресов текущего фрейма (в rbp на x86_64), и на стек не сохраняется адрес предыдущего по call-stack фрейма(push $rbp;mov $rsp, $rbp), поэтому где именно этот адрес возврата неизвестно. Для отладки используют отладочную информацию, например в форматах DWARF или ORC — из нее можно для любой точки кода функции получить позиции на стеке адреса возрата и локальных переменных.
РМ>Отдадочная информация в рантайме не используется, собираются только адреса. Отладочную информацию применяю уже потом отдельной утилитой.
Думаю можно собрать бинарники с отладочной информацией, и лучше включить frame-pointers. Но с arm/android я почти не работал.
РМ>Я в этом совсем профан и возможно скажу глупость: как вообще могут функции работать без stack-frame pointers? Процессор же должен куда-то перейти по return? В каком-то виде эта информация обязана быть. Вот её и надо извлечь.
Адрес возрата на стеке в любом случае есть. Без frame-pointerов нет адресов текущего фрейма (в rbp на x86_64), и на стек не сохраняется адрес предыдущего по call-stack фрейма(push $rbp;mov $rsp, $rbp), поэтому где именно этот адрес возврата неизвестно. Для отладки используют отладочную информацию, например в форматах DWARF или ORC — из нее можно для любой точки кода функции получить позиции на стеке адреса возрата и локальных переменных.