GDB as a Thread Debugger on top of the TDI

 
description of changes 

The commands step, stepi, next and nexti  are based on the function step_1. To provide the appropriate threadspecific commands  named ptstep, ptstepi, ptnext and ptnexti we have to change the stop criterion used in step_1. If we stop in the next line or at the next instruction, we have to test the current thread. If it is not the same as before running the command (this means, that we have lost the control flow of the thread), we have to continue running the program until the former control flow is reached. 

bugfix for recursive calls of wait_for_inferior:

wait_for_inferior is the function called by proceed() to wait for any program event signalled by the operating system by making the function wait return. wait_for_inferior calls the function breakpoint_thread_match before deciding to proceed again, if it was the wrong thread. Calling the function breakpoint_thread_match can cause a TDI usage. If we debug an application using a User Space Implementation of the Pthreads, a function call is done  in the target. The consequence of a target function call in this situation is a recursive call of wait_for_inferior. After target function call is completed, the flag breakpoint_inserted is unset. This is a wrong assignment, because the breakpoint we were calling breakpoint_thread_match at is not unset. The bugfix is very simple by setting the flag  breakpoint_inserted.

switch off scheduling while resetting the breakpoint:

If the current breakpoint was reached from the wrong thread, we have to pass this breakpoint by resetting the instruction, single stepping and resetting the breakpoint after this single step. While single stepping the application, no breakpoint is set. This a critical point, because other threads can be scheduled in and pass the breakpoint without stop. To avoid this scenario, we switch off signal handling in user space implementations by changing the signal handing policy of the pthreads implementation. switching off is done by setting a flag in the target process. this flag is a symbol, that is defined in every TDI compliant pthread implementation.

breakpoint_thread_match: 

breakpoint_thread_match is the function used by wait_for_inferior to test the validity of a threadspecific breakpoint. Because there is the abilty for the user to specify threadspecific breakpoints for POSIX threads now, some changes were made to test the validity of a POSIX threadspecific breakpoint.

the keyword pthread is accepted by the break command. some parsing and assignment stuff is added. 

target_new_objfile is defined as a function call to pTDI_new_objfile to initialize the thread debugging. The GDB does a target_new_objfile on every object file load. The application has to know, whether it is thread debugged or not. If it is, it loads the TDI library and register it's TED functions (functions to access object attributes and iterate object sets). Because we have to set the thread debug mode of the application before running it, it's the best way to detect a pthread application while scanning the loaded object files for pthread symbols. Setting the debug mode is done by writing the global symbol pthread_debug_with_TDI, that has to be defined in a TDI compliant pthreads implementation.