This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch] Error reporting during insert_breakpoints
- From: Pedro Alves <pedro at codesourcery dot com>
- To: gdb-patches at sourceware dot org
- Cc: Michael Snyder <msnyder at vmware dot com>
- Date: Wed, 3 Jun 2009 22:46:44 +0100
- Subject: Re: [patch] Error reporting during insert_breakpoints
- References: <4A26E026.2000705@vmware.com>
On Wednesday 03 June 2009 21:42:14, Michael Snyder wrote:
> Two small changes
>
> 1) If insert_breakpoints fails during stepping, "keep_going()"
> contains a TRY_CATCH block, but does not print the exception error.
> If the same thing happens during continue, "catch_errors" reports it.
Yes, please. This silent stop bites me often, when longjmp-resume
breakpoints fail to insert due to glibc pointer mangling...
> 2) insert_bp_locations() generates error text that assumes
> memory breakpoints. Confusing if remote_insert_breakpoints
> is using Z0.
Strictly speaking, Z0 breakpoints *are* supposed to have
memory breakpoints semantics. :-)
@item z0,@var{addr},@var{length}
@itemx Z0,@var{addr},@var{length}
@cindex @samp{z0} packet
@cindex @samp{Z0} packet
Insert (@samp{Z0}) or remove (@samp{z0}) a memory breakpoint at address
@var{addr} of size @var{length}.
> @@ -1223,10 +1223,10 @@ Note: automatically using hardware break
> else
> {
> fprintf_unfiltered (tmp_error_stream,
> - "Cannot insert breakpoint %d.\n",
> + "Cannot insert breakpoint %d",
> bpt->owner->number);
> fprintf_filtered (tmp_error_stream,
> - "Error accessing memory address ");
> + " at memory address ");
> fputs_filtered (paddress (bpt->address), tmp_error_stream);
> fprintf_filtered (tmp_error_stream, ": %s.\n",
> safe_strerror (val));
I'm not objecting to the change, but, honestly, I don't see where
the assumption was, or where it is being removed?
--
Pedro Alves