Re: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ??

[Masahiro Fukuda <masahiro at lsi dot nec dot co dot jp>]

Hi Conklin-san,

Thanks for your prompt reply after reading all of my
proposal and understading it correctly.   To tell the
truth, I've been afraid of my illustration as well as 
my English :-)

Your reply is rich in thoughts.   Yes, my idea depends
on how gdb-4.18 manages breakpoints;i.e inserting
breakpoints brefore continue, and removing breakpoints
after target stops.  My stub code is watching breakpoints-
insert in order to add ignore counts for breakpoint packet 
and is watching breakpoints-remove in order to retrieve 
remained ignore count from target.

Further, you gave me a point to be refined for RTOS use.

I regretted that my proposal should conflict with your 
current project.   In your idea, I guess you would 
leave breakpoints (software breakpoints as well as
hardware breakpoints? ) when target stops.  You would
carefully replace inserted TRAP instructions with
original instuctions for software breakpoints when
disassembling target instructions.   You would just 
remove breakpoints from target when breakpoints are 
deleted/disabled by programmer or target hits temporary 
breakpoint.  And you would insert breakpoints into
target when breakpoints are made/enables by programmer.
Not when continue command is invoked but breakpoints
related command is invoked?

Let me adjust my samll stub code after releasing gdb 
that will have new method to handle breakpoints with 
additional command that lists managed breakpoints and 
their ignore count (if any).    Until then, I will keep 
my stub code for gdb as *temporary* use :-)

I might add <thread-id> or <task-id> when target is 
running under some kind of RTOS(Yes, I could have ITRON 
for my target).   Adding <task-id> should enable gdbserver 
to continue target without disturbing gdb when gdbserver
knows RTOS internal working area especially <task-id>.
Or sequential condition, that some ICEs provide, might be 
exploited to have a non-waste thread-sensitive ( or task-
sensitive) break.

Thanks again for your comment.

Best regards,
Fukuda, M


From: jtc@redback.com (J.T. Conklin)
Subject: Re: one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ??
Date: 23 Sep 1999 13:51:08 -0700

> >>>>> "Masahiro" == Masahiro Fukuda <masahiro@lsi.nec.co.jp> writes:
> Masahiro> My name is Masahiro Fukuda.  Independently, I added some
> Masahiro> keyword (actually [B/b] just like J.T.C did) into gdb serial
> Masahiro> protocol in order to transmit "breakpoint" to gdbserver
> Masahiro> instead of writing TRAP instruction.
> 
> Masahiro> Some arguements including <addr>, <length>, <ignore_count>
> Masahiro> follow breakpiont keyword in my code.  Those command packets
> Masahiro> are generated in v850_insert_hw_breakpint()/
> Masahiro> v850_insert_watchpoint() in v850-tdep.c.
> 
> I didn't think about breakpoints with ignore counts when developing
> the breakpoint extension proposal.  I did want to allow the stub to
> manage thread specific breakpoints, which are similar.  I also spent
> some time thinking about how to support conditional breakpoints.  My
> current thoughts are to use an easily parsed stack based expression
> syntax, but I'm not actively pursuing this feature.
> 
> The problem with breakpoints with ignore counts is the synchronization
> of the count between GDB and the stub.  As I understand your proposal,
> you address this by having the 'remove breakpoint' command return how
> many counts are left for each breakpoint.
> 
> Unfortunately, I believe that this conflicts with another project that
> I'm working on.  I've been changing GDB so that breakpoints are not
> inserted or removed from the target unless it is absolutely necessary
> to do so.
> 
> At present, whenever you step through code, the active breakpoints are
> inserted, the code is executed, then the breakpoints are removed.  If
> the user is using a lot of breakpoints, this greatly increases the
> time it takes to step through code.
> 
> If GDB must sync ignore counts by removing breakpoints, that precludes
> this optimization.  Perhaps an additional command that lists managed
> breakpoints and their ignore count (if any) is needed.
> 
> Another possible problem is that our current model is that duplicate
> breakpoints are ignored when they are inserted.  A breakpoint is
> uniquely defined by <type>, <addr>, <len>, and possibly <thread-id> if
> threads specific breakpoints are supported.  But how can the stub tell
> the differences between two breakpoints when the only difference is
> the ignore count?  This may require the stub to return a handle when a
> breakpoint is inserted so that GDB can uniquely identify it.
> 
> I'm not saying this is a bad idea.  Actually, this is the kind of
> thing a stub can keep track of fairly trivally yet greatly reduce 
> the amount of debug protocol overhead.  But I think it needs a bit 
> more refinement.
> 
> Thoughts?
> 
>         --jtc
> 
> -- 
> J.T. Conklin
> RedBack Networks