This is the mail archive of the gdb-patches@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 packet


>> I think this needs to be the default.

Andrew> I'm not convinced.  The situtation we have here is in fact
Andrew> slightly than the situtation we currently have with memory.

Andrew> The spec should (but doesn't) state that set/clear breakpoint
Andrew> operations should be identpotent :-( This was suggested when
Andrew> the packet was originaly discussed.

Ok, given that requirement, a lost or duplicate packet will not be as
disasterous as I thought.

Here are some additional restrictions I think should be in the break-
point packet specification.  For the the most part, these are easy to
implement in the debug agent, and open up optimization opportunities
GDB will be able to take advantage in the future.

  * If a thread is selected, the debug agent SHOULD NOT return control
    to GDB unless the breakpoint is triggered in that thread.

This eliminates latency which is otherwise introduced when the agent
returns control to GDB, GDB queries the agent for the current thread,
determines the breakpoint is not set on that thread, and then tells
the agent to continue.

This is a SHOULD NOT instead of a MUST NOT because things will operate
correctly as long as the current behavior of GDB querying the current
thread and continuing if the thread id's are different is maintained.


  * The agent MUST be able to step or continue of a breakpoint without
    removing it.

The remove breakpoint, step, insert breakpoint, continue dance has a
high overhead.  As is relatively easy to implement in the debug agent,
we should require it now.  Otherwise, it will be impossible for GDB to
take advantage of later.


  * The agent MUST adjust the PC when a breakpoint is hit (ie. make it
    look like DECR_PC_AFTER_BREAK and DECR_PC_AFTER_HW_BREAK == 0).

This is another high overhead operation.  GDB must fetch the value of
the PC, adjust it, and then store it.  If the agent doesn't implement
the 'T' response and the 'P' store single register command, GDB is
forced to use 'g' and 'G' to fetch and store all registers.

Unfortunately, I don't know whether this is possible.

It would be easier if the agent was required to adjust the PC for
all breakpoints, even those set by inserting breakpoint instructions.
Then DECR_PC_AFTER_BREAK, etc. could simply be set to 0.  But there
are a lot of stubs out there that don't do the PC adjustment.

It might be more managable if DECR_PC_AFTER_BREAK, etc. were target
vector specific.  I'm a little surprised they aren't, I figured that
at least some of the ROM monitors for processors that increment their
PCs in breakpoint instructions would do the adjustment themselves.


  * The agent MUST reject the command if extra fields are encountered.

There are no opportunities for extending the insert/remove breakpoint
commands if they agent only parses the currently specified fields and
ignore anything that might be leftover.  One idea I have is for a
small expression that can be evaluated when a breakpoint is triggered.
GDB may be able to distill a conditional breakpoint into such an
expression.  This kind of feature could greatly reduce the cost of
conditional breakpoints.


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