Not implemented.We would rather like to work on the formalization of
per thread flags and global flags that are much more general than any kludge
we could implement,
[(I2)]:
We have tried two solutions in our prototype. The first one was to use
the idle thread context contained in the Registers task control
block field. The drawback of this solution was that we had to implement specific
code for the continue operation immediately following the attach command. We
then decided to create a dedicated task that will only exist during the attach
phase. This task will call the ``ENTER_RGDB'' exception. This call will execute
the Exception Handler that saves a valid context and that notifies a change
to GDB. After the first CONTINUE command from GDB, this task will continue its
execution and delete itself,
[(I3)]:
As explained above in the synchronization chapter, we choose to serialize
events in a way that makes GDB think the system is frozen,
[(I4)]:
As a temporary fix, we have called rtems_task_suspend and used
the context switch contex for tasks that are unknown to RGDBSD,
[(I5)]:
Not Implemented yet. If I remember correctly, setting the frame pointer
to 0 at task initialization for CISC processor solves this problem (ebp = 0x0
on Intel or a6 = 0x0 on 680x0). This should be done in rtems_task_create function
in the path to really starts the task for the first time. The processor/system
specific stop condition can be found as macros in the GDB source tree.
RTEMS Remote Debugger Server Specifications