Re: breakpoint insert API (was: A patch for ia32 hardware watchpoint.)

[Stephane.Bihan@arccores.com]

>
> Stephane> I also use the breakpoint structure as an extern variable. I
> Stephane> needed it to implement the set_hw_breakpoint routine for the
> Stephane> remote protocol.  I think it's not the nicer way to do but
> Stephane> ....
>
> Can you explain?  I don't see any use of struct breakpoint in the
> current arc-tdep.c, nor do I see a set_hw_breakpoint function?

The version at FSF is a very old version out of date.
I am currently extending gdb for ARC to support user extensions.

>
> >> Since you say you can remove the single step code, I assume that the
> >> ISS target and remote protocol agents can perform the single step by
> >> themselves?  If so, it would be advantageous to disable GDB's single
> >> step support.  GDB would then issue a single "step" command instead of
> >> "insert breakpoint(s)", "continue", and "remove breakpoint(s)".  The
> >> latency of a step should be greatly improved.
>
> Stephane> I will implement this for the remote target only since the
> Stephane> hardware supports single-stepping.  I'm not sure if this
> Stephane> feasible in the ISS - Yuri?
>
> Stephane> If not feasible I won't disable the GDB's single step
> Stephane> support (thus enabling a call to single_step()) but I will
> Stephane> implement a single_step call to gdbstub in remote_resume().
>
> If your ISS target cannot support single step, but the remote protocol
> can, perhaps the best thing is to make software single step a target
> specific option.

By creating a target specific command?
The single step mechanism is a not a step-over-calls mechanism.

>
> I don't think that the arc is the only processor that would benefit
> from such a change.  For example, the sparclet ROM monitor supports a
> single step command, but I do not know if it is ever issued because
> the SPARC target uses software single step.  Perhaps it inserts the
> trap instructions needed for single step and issues the monitor step
> command?
>
> I do not think it's possible for any change to remote_resume() to be
> the right solution.
>
You're right, I've tried and if does not work.
Thanks for your explanations anyway.

Stephane.

----------------------------------------------------------------
Stephane Bihan
ARC Cores Ltd            http://www.arccores.com