Community
Participate
Working Groups
I have an application with many threads on a embedded system that I debug remotely with CDT. The debugger will correctly stop on breakpoints, however something causes GDB to immediately move to the last thread in the thread list whenever execution breaks, and I can't get any context information for the thread where the breakpoint happened. So if I have 20 threads and thread #4 hits a breakpoint, the execution will pause, but the GDB context will be moved to thread #20, and I cannot inspect the state of thread #4 beyond what the stack shows in the debug view. If I click thread #4 in the view, the view moves to thread #20 and thread #20 will be highlighted. If I enter "thread 4" in the gdb console I get similar results. If thread #20 happens to be in a section of code with debug info, I can look around and inspect thread #20, but nothing else. I'm seeing this on Oxygen.2: Eclipse 4.7.2, CDT 9.4.0 which happens to be the current build in arch linux repos. Using an arm cross toolchain, but this does not happen with the same toolchain and application in Neon.3 CDT release (9.2.1)
After testing various versions of Eclipse/CDT back through Oxygen M4 (CDT 9.2.0) I found that this actually seems tied to the workspace - I'd created a different one originally for testing Neon, which did not exhibit the bad behavior. Using this neon workspace with oxygen also did not exhibit the behavior. Behavior was not exhibited when creating a new workspace from scratch on Oxygen.2/9.4.0 release.