From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1270 invoked by alias); 21 Oct 2003 00:04:35 -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 1262 invoked from network); 21 Oct 2003 00:04:34 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 21 Oct 2003 00:04:34 -0000 Received: from gnu.org (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 62BE42B89; Mon, 20 Oct 2003 20:04:33 -0400 (EDT) Message-ID: <3F947811.6030805@gnu.org> Date: Tue, 21 Oct 2003 00:04:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030820 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Elizabeth Chastain Cc: brobecker@gnat.com, gdb-patches@sources.redhat.com Subject: Re: [rfa/testsuite] test script for pr gdb/1056, divide by zero in gdb References: <200310181701.h9IH1Ngb020955@duracef.shout.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-10/txt/msg00632.txt.bz2 > Joel asks: > >> What is our policy regarding the insertion of URLs pointing to GDB PRs, >> or URLs in general? I would prefer that we actually copy the relevant >> information from the URL rather than inserting the URL. > > > I'm not aware of an actual policy about this. I'm not either. While ".../gdb/bugs/" will out last any switch to mozilla (re-number over my dead body :-), I don't think people will appreciate having "redhat" embedded in the file. I'd just stick to quoting the GDB pr number and any relevant text. > I like the URL because the PR database is the central repository > for information about bugs in gdb. It's easy for anyone to add new > information to the PR database, but it requires an FSF copyright > assignment and maintainer approval to add information to a test case. > > I think that this test case has enough information even if > the PR database disappears. Specifically: > > # When SIGFPE happens, the operating system may restart the > # offending instruction after the signal handler returns, > # rather than proceeding to the next instruction. This happens > # on i686-pc-linux-gnu with a linux kernel. If gdb has a naive > # signal handler that just returns, then it will restart the > # broken instruction and gdb gets an endless stream of SIGFPE's > # and makes no progress. > > If you want even more text in the test case, I'm open to patches. Anyway, yes ok. Andrew