This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A possible super feature to add to gcc
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 <AspertameMan@att.net>:
>
> >
> > 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.
>