This is the mail archive of the
archer@sourceware.org
mailing list for the Archer project.
Re: [patch] Add watchpoint support to save_breakpoints.py (and add supporting methods to python-breakpoint.c)
- From: Tom Tromey <tromey at redhat dot com>
- To: Phil Muldoon <pmuldoon at redhat dot com>
- Cc: Project Archer <archer at sourceware dot org>
- Date: Fri, 31 Jul 2009 12:21:32 -0600
- Subject: Re: [patch] Add watchpoint support to save_breakpoints.py (and add supporting methods to python-breakpoint.c)
- References: <4A310C5F.5000407@redhat.com>
- Reply-to: Tom Tromey <tromey at redhat dot com>
I'm sorry for the long delay on this.
Phil> +@defivar Breakpoint expression
Phil> +This attribute holds the breakpoint expression, as specified by
Phil> +the user. It is a string. This attribute is not writable.
Phil> +@end defivar
This should mention that the expression is only valid for watchpoints.
And, I think this patch should update the documentation to mention that
the location field is only valid for breakpoints.
Then, the corresponding getter functions should enforce this constraint.
It seems a little strange to have both address and expression. I wonder
if we should just make up a new attribute name encompassing both.
It seems like there should be a BP_ constant for a temporary breakpoint.
What do you think?
Phil> + {"BP_NONE", bp_none},
Phil> + {"BP_BREAKPOINT", bp_breakpoint},
Phil> + {"BP_WATCHPOINT", bp_watchpoint},
Phil> + {"BP_HARDWARE_WATCHPOINT", bp_hardware_watchpoint},
Phil> + {"BP_READ_WATCHPOINT", bp_read_watchpoint},
Phil> + {"BP_ACCESS_WATCHPOINT", bp_access_watchpoint},
Add a space after each "{" and before each "}".
Phil> + BPPY_REQUIRE_VALID ((breakpoint_object *) self);
Phil> + str = ((breakpoint_object *) self)->bp->exp_string;
The repeated casts here look ugly.
I agree that omitting catches and other thing is ok. I wonder, however,
whether we should simply skip those in gdbpy_breakpoint_created.
Tom