A possible super feature to add to gcc

A possible super feature to add to gcc

[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.
 
  If gcc does not have a similar function call I feel there would be
 people using gcc in the scientific community that very well might
 appreciate CALL FDUMP being resurrected. 

Re: A possible super feature to add to gcc

[Basile Starynkevitch]

On Sun, 05 Dec 2010 14:30:40 -0600
Aspertame Man <AspertameMan@att.net> wrote:

> 
>  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.
>  
>   If gcc does not have a similar function call I feel there would be
>  people using gcc in the scientific community that very well might
>  appreciate CALL FDUMP being resurrected. 

You probably are thinking of a new builtin or intrinsic function.
It could be interesting, but it probably is not of general interest to
the entire GCC community (which these days is quite conservative on the
language extensions it accept).

That could be an interesting project for a GCC plugin or a GCC MELT
(see www.gcc-melt.org or http://gcc.gnu.org/wiki/MELT for more)
extension. Maybe your company could fund someone (perhaps starting with
a very good intern interested) to do such work. I would imagine that it
could take a few months (at least for a person not extremly familiar
with GCC internals). 

If you fund an intern to explore doing the work using GCC MELT, I would
be delighted to help him on the MELT specific.

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***

Re: A possible super feature to add to gcc

[Joern Rennecke]

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.

Re: A possible super feature to add to gcc

[Aspertame Man]

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.
> 

Re: A possible super feature to add to gcc

[Richard Kenner]

> 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.

I'm confused.  Why isn't "abort" the function that you want?

Re: A possible super feature to add to gcc

[Andreas Schwab]

Aspertame Man <AspertameMan@att.net> writes:

> 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.

Try looking for gcore.

Andreas.

-- 
Andreas Schwab, schwab@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: A possible super feature to add to gcc

[Frank Ch. Eigler]

AspertameMan wrote:

>  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. [...]

This sounds like a job for a scriptable debugger, or systemtap
   probe process("a.out").statement("*@file.c:444") { log($$vars$$) }
or somesuch run-time tool.

- FChE