From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17308 invoked by alias); 6 Dec 2010 11:49:06 -0000 Received: (qmail 17292 invoked by uid 22791); 6 Dec 2010 11:49:05 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from fencepost.gnu.org (HELO fencepost.gnu.org) (140.186.70.10) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 06 Dec 2010 11:48:59 +0000 Received: from eggs.gnu.org ([140.186.70.92]:44322) by fencepost.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.69) (envelope-from ) id 1PPZYs-0003jp-W1 for gcc@gnu.org; Mon, 06 Dec 2010 06:48:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PPZYm-0002cO-Bf for gcc@gnu.org; Mon, 06 Dec 2010 06:48:57 -0500 Received: from nm25.bullet.mail.sp2.yahoo.com ([98.139.91.95]:36757) by eggs.gnu.org with smtp (Exim 4.71) (envelope-from ) id 1PPZYm-0002bx-0i for gcc@gnu.org; Mon, 06 Dec 2010 06:48:48 -0500 Received: from [98.139.91.63] by nm25.bullet.mail.sp2.yahoo.com with NNFMP; 06 Dec 2010 11:48:47 -0000 Received: from [98.139.91.53] by tm3.bullet.mail.sp2.yahoo.com with NNFMP; 06 Dec 2010 11:48:47 -0000 Received: from [127.0.0.1] by omp1053.mail.sp2.yahoo.com with NNFMP; 06 Dec 2010 11:48:47 -0000 Received: (qmail 14419 invoked from network); 6 Dec 2010 11:48:46 -0000 Received: from [192.168.1.66] (AspertameMan@70.139.53.41 with plain) by smtp101.sbc.mail.gq1.yahoo.com with SMTP; 06 Dec 2010 03:48:46 -0800 PST X-Yahoo-SMTP: sSEmoCCswBDEkwSKpLyyG9SWfNNUD7yRusPXEdqYiQMz Subject: Re: A possible super feature to add to gcc From: Aspertame Man To: Joern Rennecke Cc: gcc@gnu.org In-Reply-To: <20101205180415.t3cf4yx7pcw84gcw-nzlynne@webmail.spamcop.net> References: <1291581040.2886.6.camel@netbook> <20101205180415.t3cf4yx7pcw84gcw-nzlynne@webmail.spamcop.net> Content-Type: text/plain; charset="UTF-8" Date: Mon, 06 Dec 2010 11:49:00 -0000 Message-ID: <1291636116.1605.81.camel@netbook> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2010-12/txt/msg00176.txt.bz2 After looking on the internet on the term "dumping core" I noticed that one had to write a piece of code to cause the crash. I noted that one had to know what to do to cause the crash to get the dump and gathered that while computer scientists and most engineers know how to do this, it is not so obvious to say biologists, chemists, physicists and other users of compilers for their research. Simply building in a small standardized intrinsic function name to a common crash function that computer scientists might write to cause a core dump would make the compiler more user friendly to the non computer science crowd. Instead of fdump call it "coredump". Second there are applications that can take hours to days to execute. These sorts of programs are not well suited for debug with an interactive debugger because of the time reason. One may likely have to wait a long time to interactively tell the program to "resume" and possibly multiple times. With coredump() the argument could be used to tell the program whether or not to resume and then the programmer could be in a meeting instead of monitoring an interactive debugger to resume. This would be even more useful if the programmer wanted to make a call to coredump() at multiple places in the program in a single execution and the scientific program may take a very long time to run unlike computer science operating systems. Standardizing a coredump intrinsic function with an argument that can trigger invoking a compiler option to resume cant take more that a couple hours by a good programer thereby adding some user friendly fit and finish for the non computer scientist crowd. I'm out of the loop unless addressed directly On Sun, 2010-12-05 at 18:04 -0500, Joern Rennecke wrote: Quoting Aspertame Man : > > > > > Back in the 1970's when we ran fortran on an IBM machine we had this > > really powerful command called CALL FDUMP that if inserted into a > > program would send the names and values of every variable, at the time > > of its call, to a printer or file. In my opinion this was much more > > useful at times than a symbolic debugger, in scientific number crunching > > applications. > > I don't see how this would be better than dumping core and resuming > execution. > I suppose you might even do a fork before dumping core, that might speed up > if you have multiple CPU cores and copy-on-write memory semantics. >