This is the mail archive of the archer@sourceware.org mailing list for the Archer project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |