From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29838 invoked by alias); 26 Jun 2004 22:52:37 -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 29804 invoked from network); 26 Jun 2004 22:52:34 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sourceware.org with SMTP; 26 Jun 2004 22:52:34 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i5QMqU7l000245; Sun, 27 Jun 2004 00:52:30 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i5QMqUoR000631; Sun, 27 Jun 2004 00:52:30 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i5QMqJGP000626; Sun, 27 Jun 2004 00:52:19 +0200 (CEST) Date: Sat, 26 Jun 2004 22:52:00 -0000 Message-Id: <200406262252.i5QMqJGP000626@elgar.kettenis.dyndns.org> From: Mark Kettenis To: mec.gnu@mindspring.com CC: david@streamline-computing.com, gdb-patches@sources.redhat.com In-reply-to: <20040626154420.265CD4B104@berman.michael-chastain.com> (mec.gnu@mindspring.com) Subject: Re: [Patch] x % 0 hangs References: <20040626154420.265CD4B104@berman.michael-chastain.com> X-SW-Source: 2004-06/txt/msg00580.txt.bz2 Date: Sat, 26 Jun 2004 11:44:20 -0400 (EDT) From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) I like your patch, although I can't approve it. There is a PR for this: http://sources.redhat.com/gdb/bugs/1056 divide by zero hangs gdb Could you a line to your ChangeLog like this: 2004-06-26 Partial fix for PR cli/1056. * valarith.c: check for zero in division and remainder evaluation. > Although there may be some systems that can healthily respond to this, I > propose a trivial patch - unless someone is going to tell me there's an > option to stop the hanging, or respond differently to the signal. Someone still has to dive into the signal handling design and fix the lower-level problem, which is analyzed in the PR. Briefly, the problem is that gdb defers the its response to the signal and returns from the signal handler, but returning from the signal handler for SIGFPE can re-execute the same instruction that hung. Fixing this is highly non-trivial. The only approach that's somewhat portable is longjmp-ing out of the signal handler, and even that seems to have its problems on some platforms. Therefore I think this patch is a very good idea. I just wonder whether just printing "Division by zero" as the error message would be enough. David, consider this patch with or without that change approved. Please modify your ChangeLog as requested by Michael though. Mark