Initialisation bug in gdb server
kjrobert at alumni.uwaterloo.ca
Thu Jul 6 15:13:41 UTC 2006
There's a minor bug in the initialisation of Till's gdb server.
Currently the daemon thread (D) runs at high priority and the helper
thread (H) runs at low priority.
As far as I can discern from the code, H must execute in order to
manually inject an interrupt and initialise the system. D waits for
this to occur in getFirstMsg called from rtems-stub.c:862.
However, if you call rtems_gdb_start from a thread (ie Init or I) with
higher priority than H, then subsequently cause a breakpoint in I,
without allowing H to run, then getFirstMsg returns and fails the assert
on line 863.
In a three thread system, a hackish work around is to sleep after
calling rtems_gdb_start and allow H to run. A better fix is to ensure H
has run and inserted the correct message prior to returning from
I have a stab at a patch if anyone (Till?) is interested.
More information about the users