schedlock.exp questions
Orjan Friberg
orjan.friberg@axis.com
Fri Aug 27 13:59:00 GMT 2004
Daniel Jacobowitz wrote:
>
> This is a twisty and nasty part of infrun. It is full of bugs and
> things that need to be rearchitected. So it's quite likely it doesn't
> work right.
Ok, I think I got the hang of it now. (Apologies if my ramblings below
are a tad long-winded.)
The actual problem for CRISv32 is that the SIGTRAPs resulting from the
"break 41 if arg!=5" breakpoint for the other threads aren't ignored,
and that seems to be due to that it's using hardware single-step.
This what happens: in schedlock.exp, after the first "break 41 if arg !=
5" breakpoint is hit, all breakpoints are removed. When we step the
current thread afterwards, the other threads all have a pending SIGTRAP
(since they also hit that same (now removed) breakpoint). At this point
we reach the following code (infrun.c:handle_inferior_event):
/* See if a thread hit a thread-specific breakpoint that was meant for
another thread. If so, then step that thread past the breakpoint,
and continue it. */
The variable thread_hop_needed determines if we should ignore the
breakpoint hit and just move on (which I guess is what we want to do
here). thread_hop_needed is set if:
* there's a breakpoint at the current location, and it's set for another
thread (not applicable in this case; the SIGTRAP comes from a now
removed breakpoint)
or
* we're software single-stepping, and the stopped ptid doesn't match the
single-step ptid (which is what saves CRIS, having software single-step).
Obviously there is some logic missing to handle this case (using
hardware single-step). I tried to add a third condition for setting
thread_hop_needed, using currently_stepping (ecs) and
!breakpoints_inserted, but that was too inclusive. Question is whether
that is the right approach at all - after all, an i686-pc-linux-gnu host
doesn't need it.
> Is this native or remote (gdbserver based)? I have some patches which
> make it substantially more reliable on slow native targets but I
> haven't had enough time to test them properly. They shouldn't affect
> remote though.
This is a gdbserver based remote target.
--
Orjan Friberg
Axis Communications
More information about the Gdb-patches
mailing list