difficulty listing threads/stacks with GDB on ARM

I'm using GNUEABI to remote debug an ARM device, I'm able to set breakpoints, step, view memory, etc.

...in general life is good

however when break arbitrarily and then type 'info threads' I do get a list of threads, but the symbols arent resolving

for example

(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 ?? ()

if I were to set a breakpoint and then wait for it to hit all threads but the one with the breakpoint would be like the above, but the thread with the breakpoint would resolve

if I try to examine the backtrace of one of these threads, what I see is something like this

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

NOTE: I dont think the stack is corrupt, rather I think gdb thinking the stack is corrupt is related to the problem and likely a hint?

ideas? - keep in mind, when a breakpoint hits the call stack looks great.

Do you have a reason to expect those threads to be executing your code? Quite often, threads are running library code or sleeping, and in either case they're not running your code. However, when you set a breakpoint in you code, it's only hit when that thread actually runs your code.

I'd bet you would see some of your code on some stack traces, though. Check it out; it will be enlightening.