Mirror of the gdb mailing list
 help / color / mirror / Atom feed
* RE: Instrcutions that must not be stepped.
@ 2006-06-09 14:12 John Yates
  2006-06-09 14:28 ` Daniel Jacobowitz
  0 siblings, 1 reply; 12+ messages in thread
From: John Yates @ 2006-06-09 14:12 UTC (permalink / raw)
  To: Daniel Jacobowitz, PAUL GILLIAM; +Cc: gdb

Daniel Jacobowitz writes:

> Nope.  You'd have to add one.  And, you'd have to be able to tell
> whether you were in the middle of a GDB-automated step or a user stepi;
> stepping multiple instructions when the user asked for one is probably
> just confusing.

To whom or what?  I would be quite happy if gdb did the right thing
and output a message to the effect that an atomic sequence was indeed
treated as atomic.  That is the count of instructions stepped changed
by one for any number of failed attempts and then one final successful
execution of the entire atomic sequence.

> Reading the instruction before stepping is going to slow down single
> stepping.  Is there some other way we can handle this?

The overhead could be ameliorated by having the status returned from
a completed single step include an optional assertion that if gdb were
to step again without altering the pc or the contents of memory at the
address referenced by the pc then that step would initiate an atomic
sequence.

With this mechanism the first attempt to single step after a period of
non-single stepped execution would need to check the first instruction;
after that the process would be self sustaining without any addition
gdb initiated instruction inspection.

Admitted this mechanism does not absolve the greater gestalt of gdb +
stub + single step break handle from needing to retrieve and inspect
instructions.  But it may push it to a point where the overhead becomes
acceptable.

/john


^ permalink raw reply	[flat|nested] 12+ messages in thread
* Instrcutions that must not be stepped.
@ 2006-06-08  2:27 PAUL GILLIAM
  2006-06-08  3:50 ` Daniel Jacobowitz
  0 siblings, 1 reply; 12+ messages in thread
From: PAUL GILLIAM @ 2006-06-08  2:27 UTC (permalink / raw)
  To: gdb

On the PowerPC, there is a provision for an atomic read-modify-right
sequence that is implemented using the "lwarx" and "stwcx" instructions.
These do not guarantee an atomic operation, but will detect its failure.
If threads are being used, then glibc functions use this sequence to
implement a lock by looping back to the start of the sequence if it was
not atomic.

When gdb is stepping through a library function, which it does under
some circumstances if there is no source for the function, it gets stuck
in this loop because the sequence will never be recognized as atomic.

The only solution is to check each instruction about to be stepped to
see if it's an "lwarx".  If not, step as usual.  If it is, then analyze
the instructions that follow; set a temporary breakpoint after the loop,
do a 'continue' and then continue stepping normally after it's been hit.

Does there currently exist an arch. independent way to detect
instruction sequences that must not be single stepped?  Failing that, is
there some hook I can use to implement this for just the PowerPC?

Should there be a new gdbarch member like 'single_step_nonstepable' that
will detect and handle non-stepable sequences?.  Or maybe a gdbarch
member like 'find_end_of_nonstepable_sequence' that returns 0 if the
instruction about be be stepped is not the the start of a non-stepable
sequence and the address of the end of the sequence (where to set a
temp. break) if it is.

Thanks for your help,

-=# Paul #=-

PS: The following hack prevents single-stepping a "lwarx" instruction.
The user can then manually find the end of the sequence, put a temp.
break there, continue, and then go back to stepping as normal.  Before
you get upset, remember I did say it was a hack and it actually allowed
a teammate to make progress on an unrelated glibc bug.

--- inf-ptrace.c        2006-01-24 14:34:34.000000000 -0800
+++ new.inf-ptrace.c    2006-06-07 13:59:02.000000000 -0700
@@ -326,6 +326,14 @@
   if (step)
     {
+      /* Horrible hack:  See if we are about to step an "lwarx"
+         instruction and abort with an error message if so. */
+      long pc = (long) read_register (PC_REGNUM);
+      long inst = ptrace (PT_READ_I, pid, pc, 0);
+
+      if ((inst & 0xfc0007fe) == 0x7C000028)
+         perror_with_name (("(barf) lwarx (barf)"));
+
       /* If this system does not support PT_STEP, a higher level
          function will have called single_step() to transmute the step
          request into a continue request (by setting breakpoints on


^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2006-06-20 23:35 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-06-09 14:12 Instrcutions that must not be stepped John Yates
2006-06-09 14:28 ` Daniel Jacobowitz
2006-06-10  0:33   ` PAUL GILLIAM
  -- strict thread matches above, loose matches on Subject: below --
2006-06-08  2:27 PAUL GILLIAM
2006-06-08  3:50 ` Daniel Jacobowitz
2006-06-16  4:36   ` PAUL GILLIAM
2006-06-17 12:26     ` PAUL GILLIAM
2006-06-18  4:57       ` Mark Kettenis
2006-06-20 20:13         ` PAUL GILLIAM
2006-06-20 22:53           ` Paul Koning
2006-06-20 23:34             ` PAUL GILLIAM
2006-06-21  1:17               ` Daniel Jacobowitz

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox