Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
* [PATCH] Add command resetbpnum for reset $bpnum
@ 2011-09-19  3:50 Hui Zhu
  2011-09-19 17:26 ` Stan Shebs
  0 siblings, 1 reply; 4+ messages in thread
From: Hui Zhu @ 2011-09-19  3:50 UTC (permalink / raw)
  To: gdb-patches ml

Hi,

I found we never set the breakpoint number back in GDB.  And sometime,
I fount that user need reset $bpnum to the current last number.
So I make a patch add command resetbpnum for reset $bpnum to the last
number of the current breakpoints.

Then we can got:
(gdb) b *0
Breakpoint 1 at 0x0
(gdb) b *0
Note: breakpoint 1 also set at pc 0x0.
Breakpoint 2 at 0x0
(gdb) b *0
Note: breakpoints 1 and 2 also set at pc 0x0.
Breakpoint 3 at 0x0
(gdb) info b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00000000
2       breakpoint     keep y   0x00000000
3       breakpoint     keep y   0x00000000
(gdb) d 3
(gdb) info b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00000000
2       breakpoint     keep y   0x00000000
(gdb) resetbpnum
(gdb) b *0
Note: breakpoints 1 and 2 also set at pc 0x0.
Breakpoint 3 at 0x0
(gdb) info b
Num     Type           Disp Enb Address    What
1       breakpoint     keep y   0x00000000
2       breakpoint     keep y   0x00000000
3       breakpoint     keep y   0x00000000


Please help me review it.

Best,
Hui

2011-09-19  Hui Zhu  <teawater@gmail.com>

	* breakpoint.c (resetbpnum_command): New function.
	(_initialize_breakpoint): Register resetbpnum_command.
---
 breakpoint.c |   17 +++++++++++++++++
 1 file changed, 17 insertions(+)

--- a/breakpoint.c
+++ b/breakpoint.c
@@ -13272,6 +13272,20 @@ iterate_over_breakpoints (int (*callback
   return NULL;
 }

+static void
+resetbpnum_command (char *args, int from_tty)
+{
+  struct breakpoint *b;
+  int num = 0;
+
+  ALL_BREAKPOINTS (b)
+    {
+      if (b->number > num)
+	num = b->number;
+    }
+  set_breakpoint_count (num);
+}
+
 void
 initialize_breakpoint_ops (void)
 {
@@ -13955,6 +13969,9 @@ The breakpoint will stop execution of th
 an instruction at any address within the [START-LOCATION, END-LOCATION]\n\
 range (including START-LOCATION and END-LOCATION)."));

+  add_com ("resetbpnum", class_breakpoint, resetbpnum_command, _("\
+Reset $bpnum to the last number of the current breakpoints."));
+
   automatic_hardware_breakpoints = 1;

   observer_attach_about_to_proceed (breakpoint_about_to_proceed);


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Add command resetbpnum for reset $bpnum
  2011-09-19  3:50 [PATCH] Add command resetbpnum for reset $bpnum Hui Zhu
@ 2011-09-19 17:26 ` Stan Shebs
  2011-09-19 19:02   ` Sergio Durigan Junior
  0 siblings, 1 reply; 4+ messages in thread
From: Stan Shebs @ 2011-09-19 17:26 UTC (permalink / raw)
  To: gdb-patches

On 9/18/11 9:16 AM, Hui Zhu wrote:
> Hi,
>
> I found we never set the breakpoint number back in GDB.  And sometime,
> I fount that user need reset $bpnum to the current last number.
> So I make a patch add command resetbpnum for reset $bpnum to the last
> number of the current breakpoints.
>
>

I tend to think this would not be a good idea.  Although I don't know 
that we have a formal requirement that breakpoint numbers are all unique 
within a session, it's certainly a common assumption that we rely on 
when looking at user transcripts, testsuite runs, etc.

So before breaking before one of the longest-standing UI design 
decisions in GDB, it seems like we ought to get a little more 
understanding of why a user might want to reset breakpoint numbering.

Stan
stan@codesourcery.com


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Add command resetbpnum for reset $bpnum
  2011-09-19 17:26 ` Stan Shebs
@ 2011-09-19 19:02   ` Sergio Durigan Junior
  2011-09-21  6:11     ` Hui Zhu
  0 siblings, 1 reply; 4+ messages in thread
From: Sergio Durigan Junior @ 2011-09-19 19:02 UTC (permalink / raw)
  To: Stan Shebs; +Cc: gdb-patches

Stan Shebs <stanshebs@earthlink.net> writes:

> So before breaking before one of the longest-standing UI design
> decisions in GDB, it seems like we ought to get a little more
> understanding of why a user might want to reset breakpoint numbering.

I second that.  I read the patch and couldn't come up with a scenario
where the user would want to use this `reset' feature.  Hui, can you
explain a bit more why you thought this would be a good idea?  I was not
convinced by your example.


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] Add command resetbpnum for reset $bpnum
  2011-09-19 19:02   ` Sergio Durigan Junior
@ 2011-09-21  6:11     ` Hui Zhu
  0 siblings, 0 replies; 4+ messages in thread
From: Hui Zhu @ 2011-09-21  6:11 UTC (permalink / raw)
  To: Sergio Durigan Junior, Stan Shebs; +Cc: gdb-patches

Sorry guys.

After a long think about this patch.
I think most issues(they are around python script) that I meet can be
handle by get the last breakpoint id from $bpnum.
So I think I will give up this patch.

But if I meet a issue that only can handle by reset $bpnum, I will post it.

Thanks for your help.

Best,
Hui

On Tue, Sep 20, 2011 at 02:56, Sergio Durigan Junior
<sergiodj@redhat.com> wrote:
> Stan Shebs <stanshebs@earthlink.net> writes:
>
>> So before breaking before one of the longest-standing UI design
>> decisions in GDB, it seems like we ought to get a little more
>> understanding of why a user might want to reset breakpoint numbering.
>
> I second that.  I read the patch and couldn't come up with a scenario
> where the user would want to use this `reset' feature.  Hui, can you
> explain a bit more why you thought this would be a good idea?  I was not
> convinced by your example.
>


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2011-09-21  3:55 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-09-19  3:50 [PATCH] Add command resetbpnum for reset $bpnum Hui Zhu
2011-09-19 17:26 ` Stan Shebs
2011-09-19 19:02   ` Sergio Durigan Junior
2011-09-21  6:11     ` Hui Zhu

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox