This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


>>>>> "Stephane" == Stephane Bihan <Stephane.Bihan@arccores.com> writes:
Stephane> What do you mean by breakpoint without a trace mode?

Processors that support hardware single step often call it instruction
trace mode or something similar.  Processors without it have to resort
to inserting trap/breakpoint/invalid instructions.

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

Stephane> I don't know what are the foo_single_step functions.

I was attempting to refer to those functions that implement single step
on all targets: arc_software_single_step(), rs6000_software_single_step,
and sparc_software_single_step().  It might have made more sense if I 
didn't forget "software_" and called it foo_software_single_step() or
maybe *_software_single_step().

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?

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

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

Yes, it's a a pointer to a breakpoint struct, but it's more than that.
I mean a breakpoint created by one of the breakpoint creation functions 
in breakpoint.c.

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

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.

        --jtc

-- 
J.T. Conklin
RedBack Networks

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]