From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14142 invoked by alias); 22 Aug 2002 22:19:03 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 14134 invoked from network); 22 Aug 2002 22:19:03 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 22 Aug 2002 22:19:03 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id PAA07691; Thu, 22 Aug 2002 15:13:09 -0700 (PDT) Message-ID: <3D656355.E623B495@redhat.com> Date: Thu, 22 Aug 2002 15:26:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Grace Sainsbury CC: gdb-patches@sources.redhat.com Subject: Re: breakpoint error messages References: <20020821142627.A10117@tomago.toronto.redhat.com> <3D655542.AF3065A0@redhat.com> <20020822173220.A12466@tomago.toronto.redhat.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00727.txt.bz2 Grace Sainsbury wrote: > > On Thu, Aug 22, 2002 at 02:18:58PM -0700, Michael Snyder wrote: > > Grace Sainsbury wrote: > > > > > > I changed insert_breakpoints to collect all the warning messages from > > > failed inserts and print them with an error after trying the whole > > > queue. This changes the functionality slightly -- the old code stopped > > > after the first failed insert of a breakpoint. I also changed the > > > error messages to be more explicit about hardware breakpoints. > > > > > > ok? > > > > Grace, thanks for the contribution. A few implementation details. > > First off, you've lost some output. > > 1) The word "Warning: ", which is generated by the 'warning' function > > (which you've replaced by fprintf_unfiltered). One instance would > > probably be enough. > > ok. > > > 2) The output of the 'memory_error' function. > > The original purpose of the change was to remove that text > 'Cannot access memory address XXXXX' doesn't seem to be meaningful in > this context. It could be meaningful. It could tell you that the breakpoint was set at an illegal address, or a non-writable one (eg. in ROM). You could just mention the fact that the failure was due to a memory access problem. > > 3) The msg "The same program may be running in another process" > > I'll add that back. > > > 4) The output of print_sys_errmsg, formerly called by infrun. > > This printed 'Unknown error' which seems to be uninformative. Hmmm... either that represents bit-rot, or maybe that's just what it prints in the context in which you tried it. Maybe it prints something useful in some other context. The purpose of print_sys_errmsg is to pretty-print an 'errno' value -- which normally would be something more useful than "unknown error". If you look at the top of insert_breakpoints, the comment explains that it is supposed to return an 'errno' value. Tell you what -- all 'errno' values are greater than zero. If the return value from insert_breakpoints is less than zero, you can skip calling print_sys_errmsg. > > Do you think you could work those back in? > > > > Then, just some textual edits. In one comment you say > > "If there wat an error", where you probably meant to say 'was'. > > And there's this: > > if (hw_breakpoint_error) > > fprintf_unfiltered (tmp_error_stream, > > "Could not insert breakpoints: ..." > > > > Seems like you might as well say "hardware breakpoints" there. > > ok. > > let me know if you really want the memory_error, print_sys_errmsg text > back. > > thanks, > > grace