Thanks so much for your answer.
sbav1 wrote:
No. More likely, there are 200-300 exeDSP threads (or so).
I thought there was one thread due to:
Code: Select all
(gdb) info threads
* 1 process 61 0x42a43158 in pthread_cond_wait@@GLIBC_2.4 () from /lib/libpthread.so.0
Of course, if gdb is not working it may not be listing the right number of threads. I'm learning, so I don't know another way of getting lists of threads or similar information.
While gdb is starting up, I do get
Code: Select all
warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available.
But, I find all of this counterintuitive. I would have thought gdb deals with threading through a kernel interface, and not by some shared library.
sbav1 wrote:Breakpoint can be set for individual threads, or for all of them (default), and it should stop ALL threads.
This would be great.
However, I don't get a SIGTRAP when the breakpoint is hit. Rather, it's as if there was no breakpoint set at all. So, while I find it surprising that threads could cause this kind of problem, I guess there's nothing to do except to use a different debugger. Do you think gdbserver might work, or is it the same thing as gdb?
sbav1 wrote:Note: attaching to individual thread works for me (using thread SPID / LWP as PID in 'attach').
I'm not clear on how to find the thread SPID / LWP of any thead, let alone figure out which thread to attach to (I just know the location of the code I want to set the breakpoint in).
I don't think I want to set breakpoints in interrupt handlers and such things. I was trying to set them in the setup code where there's printfs with debugging information. If the thread doesn't like being stopped/traced, I guess I'll reboot the TV. But the problem isn't the the TV is messed up, it's that the breakpoint does absolutely nothing.