Software single-stepping and multi-arch

[Richard Earnshaw]

SOFTWARE_SINGLE_STEP_P() is currently part of the gdbarch vector 
(actually, it's implicit, since in a multi-arch system it just tests 
whether the SOFTWARE_SINGLE_STEP hook is non-null).  However, I'm 
beginning to wonder if this is really correct.

The basic concept of the gdbarch vector is that it can be set up by 
examining the bfd object description for the inferior and then deciding 
what to set certain values to.  But how can the ability to single-step a 
target really be decided by looking at an object file?

The answer is that it can't, except in a few cases where we can infer 
about the target based on the OS that the image requires.

Consider the arm-elf configuration.  This is a generic elf format file 
that might be run on a range of hardware (or simulators) over a variety of 
interfaces; and yet we are supposed to be able to tell, by looking at this 
file, whether the inferior can single-step it or not!

This leads me to conclude that SOFTWARE_SINGLE_STEP_P() should logically 
be part of the target_ops structure, not the gdbarch structure.  Then we 
can set this up once we know the connection method to the inferior and can 
'talk' to the real target.  The ARM RDI, for example, has a command that 
can query the target to find out if it is capable of single-stepping 
directly, or if the debugger must do it with breakpoints: but at present 
we have no way of using this, because the ARM tdep code cannot assume that 
we will be using RDI (indeed, we won't in many cases).

The funny thing is that SOFTWARE_SINGLE_STEP itself (the function that 
allows gdb to step the inferior manually) should be part of gdbarch (since 
it must be provided by the tdep code and *is* independent of the 
inferior).  It's just the predicate saying whether to use it or not that 
is in the wrong place.

Should we separate the two out?

Comments?

R.