сложность перечисления потоков / стеков с GDB на ARM - PullRequest
Новая
       16

сложность перечисления потоков / стеков с GDB на ARM

1 голос
/ 28 августа 2011

Я использую GNUEABI для удаленной отладки устройства ARM, я могу установить точки останова, шаг, просмотреть память и т. Д.

... в общем жизнь хороша

однако, когда произойдет произвольный перерыв, а затем наберет 'info threads', я получу список потоков, но символы не разрешаются

например 

(gdb) info threads
  7 Thread 10283  0x402a42a4 in ?? ()
  6 Thread 10282  0x402a42a4 in ?? ()
  5 Thread 10281  0x401c9d68 in ?? ()
  4 Thread 10280  0x401c9d68 in ?? ()
  3 Thread 10279  0x401cb3f4 in ?? ()
 *2 Thread 10278  0x401cb294 in ?? ()
  1 Thread 10195  0x0001c5e0 in ?? ()

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

если я попытаюсь изучить обратную трассировку одного из этих потоков, то я увижу что-то вроде этого 

(gdb) bt
#0  0x003d0f00 in ?? ()
#1  0x0000027f in ?? ()
#2  0x00000277 in ?? ()
#3  0x4360c4e0 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

ПРИМЕЧАНИЕ. Я не думаю, что стек поврежден, скорее, я думаю, что GDB считает, что стек поврежден, связано с проблемой и, вероятно, с подсказкой?

идеи? - имейте в виду, что когда точка останова попадает в стек вызовов, выглядит великолепно.

1 Ответ

0 голосов
/ 07 сентября 2011

Есть ли у вас основания ожидать, что эти потоки будут выполнять ваш код?Довольно часто потоки запускают код библиотеки или спят, и в любом случае они не запускают ваш код.Тем не менее, когда вы устанавливаете точку останова в своем коде, она срабатывает только тогда, когда этот поток действительно выполняет ваш код.Проверьте это;это будет поучительно.

...