one proposal ... `Z'T`,'ADDR`,'LENGTH`,'IGNORE_COUNT ??
Masahiro Fukuda
masahiro@lsi.nec.co.jp
Mon Sep 27 04:02:00 GMT 1999
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
More information about the Gdb
mailing list