Re: Powerpc and software single step

[Andrew Cagney <ac131313 at redhat dot com>]

> > > > > > "AC" == Andrew Cagney <ac131313@redhat.com> writes:
>
>
>  AC> It may be possible to wrap software single step's predicate in a 
>  AC> function that, like the remote protocol, returns the predicate, or 
>  AC> always false.
>  >> 
>  >> It is my understanding that the predicate is use to conditionally wrap
>  >> the "vector" is it usefull for the predicate to be anything more then
>  >> a boolean in gdbarch?
>
>  AC> Sorry, I don't understand your question.
>
> Ok, its probably my lingo shortcommings.
> the ppc trees still use the olf MACROS:
>   SOFTWARE_SINGLE_STEP_P (the predicate?)
>   SOFTWARE_SINGLE_STEP   (the function which is the gdbarch "vector")

What about a patch to eliminate the macros?  Good incremental step.

> since the eval of the predicate is checked before the function is
> called I opted to toy with the predicate in is macro form to decide
> its value.  Unfortunately in gdbarch land the predicate
> simply tests for the vector being !=NULL.
>
> So my quiestion is really about introducing a boolean to gdbarch that
> can changed by some user action (such as set).  But if it is the "test
> then call" itself that you are objecting to then obviously this will
> not solve that.

Once created, the architecture object doesn't change - it's describing 
the architecture and not the UI state.

There are a number of factors that determine if software single step 
should be used:

- architecture supports/implemented it
- target doesn't support hardware single step (to be done)
- user requested that software/hardware stepping be used (your addition)

I suspect that both Daniel and I are (each in a round about way) 
suggesting that the code be modified to use a function containing all 
those tests.

Andrew