Re: Spurious SIGTRAP reported by GDB 6.8 when debugging embedded RTOS application

[Antony KING <antony dot king at st dot com>]

This change in behaviour looks like it has occurred as a result of some
structural changes in infrun.c. After a quick scan I can see numerous
(related I think) changes which are possible candidates for this
behavioural change, and all in the area of single stepping :-).

It looks like that these changes have been made in order to improve the
expected behaviour of GDB when debugging multi-threaded applications;
unfortunately while this is OK for debugging user processes on OS's such
as Linux it does not fit nicely onto my RTOS :-(.

I suspect that your explanation about the behaviour of "next" when the
target stopped due to a breakpoint may be implicated in this change :-).

I do not know what the "right" solution in general is, but for my RTOS I
think the only recourse is to ensure that the last stopped thread is
selected before performing a step operation.

Cheers,

Antony.

Pedro Alves wrote:
> On Monday 18 August 2008 13:42:05, Daniel Jacobowitz wrote:
>> On Mon, Aug 18, 2008 at 11:20:23AM +0100, Antony KING wrote:
>>> Thanks for the explanation. Unfortunately GDB has no influence over the
>>> RTOS, it is merely an observer. This means that it cannot change the
>>> status of threads or decide which thread is to execute; this is solely
>>> under the control of the RTOS.
> 
> What is confusing me a bit, is that you claim that this is a new
> behaviour in 6.8, coming from 6.7.1.  What was it that changed between
> 6.7.1 and 6.8?  That is, why did it work in 6.7.1 ?
> 
> Note that if the user switches threads when stopped at a breakpoint, and
> the user issues "next", gdb will first revert back to the thread that
> hit the breakpoint originally, do a single-step to get over the breakpoint,
> and then when that finishes, reverts back to the new thread the user had
> selected, to proceed with the "next" command.