Re: [patch] Error reporting during insert_breakpoints

[Pedro Alves <pedro@codesourcery.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