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

[Stephane dot Bihan at arccores dot com]

> >>>>> "Stephane" == Stephane Bihan <Stephane.Bihan@arccores.com> writes:
>
> jtc> One issue that I'm not sure how to address is that there are several
> jtc> places breakpoints are inserted where a breakpoint has not been
> jtc> constructed.  Most of these occur in tdep code which implements single
> jtc> step with breakpoints on processors without a trace mode.
>
> Todd> Aiee! Such code is evil and must be destroyed.
>
> Stephane> It seems to me that this single_step function is actually
> Stephane> not in use.  I don't know about WindRiver, but here we have
> Stephane> two targets: an ISS and a remote target that use the generic
> Stephane> breakpoint functions before stepping.  I don't mind to
> Stephane> remove this code.
>
> I assume you are refering to the ARC port?

yes. But I was actually wrong in my last email, the single step function in
arc-tdep is
used, I was thinking to another function, sorry.
What do you mean by breakpoint without a trace mode?

>
> I see three GDB ports that do single step in software: arc, rs6000,
> and sparc.  The arc and sparc ports, insert breakpoints with target-
> _insert_breakpoint().  The rs6000 port by reading and writing memory
> directly.  Of the two methods, I prefer target_insert_breakpoint().
>
> However, if the breakpoint insert/remove API was changed to require a
> struct breakpoint pointer, we couldn't call target_insert_breakpoint()
> in the foo_single_step() functions without creating a real breakpoint
> object to pass through that first pointer.

I don't know what are the foo_single_step functions.

I also use the breakpoint structure as an extern variable. I needed
it to implement the set_hw_breakpoint routine for the remote protocol.
I think it's not the nicer way to do but ....

> Another reason we might want a real breakpoint for this is that when
> my memory region attribute code is complete we'll be able to say that
> breakpoints in a region should be done with hardware breakpoints.
> A user can debug his/her own code in read-only memory by using hbreak,
> but there is no way to tell GDB to use hardware breakpoints for step,
> next, continue, finish, until, etc.  One thing that surprised me was
> that the single step code used multiple breakpoints.  That would put a
> lot of pressure on hardware breakpoint registers.  I suspect that GDB
> has all the information in order to insert a single breakpoint (by
> evaluating which way a conditional branch will go, etc.).
>

What would be a "real breakpoint"? a pointer to the breakpoint structure?

>
> 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.

I will implement this for the remote target only since the hardware supports
single-stepping.
I'm not sure if this feasible in the ISS - Yuri?

If not feasible I won't disable the GDB's single step support (thus enabling a
call to single_step())
but I will implement a single_step call to gdbstub in remote_resume().

Stephane.

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