From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15608 invoked by alias); 5 Nov 2011 17:35:21 -0000 Received: (qmail 15388 invoked by uid 22791); 5 Nov 2011 17:35:20 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-fx0-f41.google.com (HELO mail-fx0-f41.google.com) (209.85.161.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 05 Nov 2011 17:35:04 +0000 Received: by faaf16 with SMTP id f16so4786920faa.0 for ; Sat, 05 Nov 2011 10:35:03 -0700 (PDT) Received: by 10.223.77.66 with SMTP id f2mr32953849fak.24.1320514503172; Sat, 05 Nov 2011 10:35:03 -0700 (PDT) MIME-Version: 1.0 Received: by 10.223.121.200 with HTTP; Sat, 5 Nov 2011 10:34:41 -0700 (PDT) In-Reply-To: References: <998639.46560.qm@web112516.mail.gq1.yahoo.com> <321260.58442.qm@web112504.mail.gq1.yahoo.com> <1316327455.23344.YahooMailNeo@web112509.mail.gq1.yahoo.com> <1316404058.27177.YahooMailNeo@web112502.mail.gq1.yahoo.com> <1318650316.91503.YahooMailNeo@web112508.mail.gq1.yahoo.com> From: =?UTF-8?B?UGV0ciBIbHV6w61u?= Date: Sat, 05 Nov 2011 17:35:00 -0000 Message-ID: Subject: Re: [PATCH] arm reversible : To: Tom Tromey Cc: paawan oza , "gdb-patches@sourceware.org" , chandra krishnappa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-11/txt/msg00131.txt.bz2 On 3 November 2011 18:38, Tom Tromey wrote: >>>>>> "Petr" =3D=3D Petr Hluz=C3=ADn writes: > > Petr> The guideline - which I think Tom was reffering to - is that > Petr> impossible states and coding bugs in gdb should trigger assertions > Petr> however user's input (no matter how malformed) should trigger warni= ng > Petr> or error messages. > > Yes, I think that rule makes the most sense. > > Petr> Some situations are difficult to decide whether they are trigger-ab= le > Petr> by user input or not. > Petr> If my code is not coded or intended to handle such situations I pre= fer > Petr> to kill the process (or whatever are assertions configured to do) a= nd > Petr> get feedback from user. > Petr> I am not familiar with GDB customs, though. Tom? > > I think crashing gdb should be limited to "can't happen" scenarios > arising from the internal logic. How strong is the "can't happen" requirement? Is programmer required to prove the assertion cannot be triggered? The difficulty in general case would be equivalent to proving a code is bug-free - i.e. it is impossible. At my job we try to verify an assumption until we have a sort-of-proof or the search becomes difficult and no clue/indication to the contrary has been found yet. I am asking because GDB code contains surprisingly few assertions. > Tripping across an unrecognized instruction or the like should just > result in an ordinary gdb error -- something the user can reasonably > recover from. > > If the error message is informative enough about what went wrong, it > will result in a bug report :-) Well, when user gets a message "assertion failed" (and the user had not messed with gdb sources) then the user knows its a bug in gdb. The user does not have to understand what code broke - application programmers generally do not have the knowledge anyway (symbols, ELF internals, debugging hooks etc). Anyway, the patch had used assertions correctly because expression `bits (X, 21, 24)' yields value in range 0..15 for any value of X - no matter how bogus X value. Yes, all 2^32 values map to 0..15. The assertions satisfy the guideline. (This is not even the hard-to-prove case I was speculating above.) --=20 Petr Hluzin