This fixes a problem noticed on ppc64-linux: automatically stepping out
of the 'puts' library function (because it had no line number
information) would cause an endless loop.  This happened because of the
following sequence of instructions:

        L1:   lwarx   r11,0,r3
              cmpw    r11,r9
              bne-    L2
              stwcx.  r0,0,r3
              bne-    L1
        L2:   isync

GDB can not single step this sequence instruction by instruction because
the 'reserve' made by the lwarx instruction will always be lost by the
the time the stwcx instruction has executed.

Other architectures may have similar instruction sequences which must
not be single stepped, one at a time.

To fix this, we must 'single step' these sequences as a whole, using the
same mechanism used by software single step.

Toward that end, I changed the existing software_single_step so that it
would return 1 if it handled the step and 0 if it did not.  All the
existing versions where changed to always return 1.

Then I added a software_single_step routine for ppc-linux.  This
platform did not previous use this function because it has a hardware
single step.  Now, this routine ('ppc_atomic_single_step') checks to see
if the instruction about to be stepped is an stwcx instruction.  If not,
it returns 0 to indicate that the single step has not been handled and
the regular hardware single step should be used.  If the instruction
about to be single stepped was an stwcx instruction, then the code is
scanned looking for the corresponding stwcx instruction, after which a
breakpoint is placed.  If a branch is detected while scanning, a
breakpoint is also placed at the target of that branch.  Then flags are
set as they where for the old software single step and 1 is returned to
indicate that the step has been handled.

I have attached two patches.  'change-software-single-step.diff' makes
the generic changes to all the existing software single step routines:
changing their type from void to int and always returning a 1.

'ppc-atomic-single-step.diff' adds the new ppc_atomic_single_step
routine to ppc-linux-tdep.c and updates the ppc_linux_init_abi routine
to use set_gdbarch_software_single_step() to plug the new routine into
the architecture vector.

You may ask "but what if an architecture needs the old
software_single_step functionality *and* has sequences of instructions
that need to be atomic?"  The answer is easy: do the test for the start
of an atomic sequence: if yes, then scan for its end as above and set
one or two breakpoints; if no, then examine the instruction to see if
it's a branch, setting a breakpoint at the target of the branch if it
is, and setting a breakpoint after the instruction if it is not or if
it's conditional.  In either event the step was handled, so return 1.

You may ask "isn't this going to take a long time, examining every
instruction before it is stepped?"  Well, a little.  But no more then an
architecture without a hardware supported single step which has to
examine every instruction to see if it's a branch.  I did some timing
analysis and the difference was minor.

This was first discussed on the gdb mailing list here:
        http://sourceware.org/ml/gdb/2006-06/msg00048.html
        
OK to commit?

-=# Paul #=-