* A possible super feature to add to gcc
@ 2010-12-05 20:30 Aspertame Man
2010-12-05 20:41 ` Basile Starynkevitch
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Aspertame Man @ 2010-12-05 20:30 UTC (permalink / raw)
To: gcc
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible super feature to add to gcc
2010-12-05 20:30 A possible super feature to add to gcc Aspertame Man
@ 2010-12-05 20:41 ` Basile Starynkevitch
2010-12-05 23:04 ` Joern Rennecke
2010-12-06 16:44 ` Frank Ch. Eigler
2 siblings, 0 replies; 7+ messages in thread
From: Basile Starynkevitch @ 2010-12-05 20:41 UTC (permalink / raw)
To: Aspertame Man; +Cc: gcc
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} ***
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible super feature to add to gcc
2010-12-05 20:30 A possible super feature to add to gcc Aspertame Man
2010-12-05 20:41 ` Basile Starynkevitch
@ 2010-12-05 23:04 ` Joern Rennecke
2010-12-06 11:49 ` Aspertame Man
2010-12-06 16:44 ` Frank Ch. Eigler
2 siblings, 1 reply; 7+ messages in thread
From: Joern Rennecke @ 2010-12-05 23:04 UTC (permalink / raw)
To: Aspertame Man; +Cc: gcc
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.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible super feature to add to gcc
2010-12-05 23:04 ` Joern Rennecke
@ 2010-12-06 11:49 ` Aspertame Man
2010-12-06 11:52 ` Richard Kenner
2010-12-06 12:20 ` Andreas Schwab
0 siblings, 2 replies; 7+ messages in thread
From: Aspertame Man @ 2010-12-06 11:49 UTC (permalink / raw)
To: Joern Rennecke; +Cc: 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.
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible super feature to add to gcc
2010-12-06 11:49 ` Aspertame Man
@ 2010-12-06 11:52 ` Richard Kenner
2010-12-06 12:20 ` Andreas Schwab
1 sibling, 0 replies; 7+ messages in thread
From: Richard Kenner @ 2010-12-06 11:52 UTC (permalink / raw)
To: AspertameMan; +Cc: amylaar, gcc
> 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?
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible super feature to add to gcc
2010-12-06 11:49 ` Aspertame Man
2010-12-06 11:52 ` Richard Kenner
@ 2010-12-06 12:20 ` Andreas Schwab
1 sibling, 0 replies; 7+ messages in thread
From: Andreas Schwab @ 2010-12-06 12:20 UTC (permalink / raw)
To: Aspertame Man; +Cc: Joern Rennecke, gcc
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."
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: A possible super feature to add to gcc
2010-12-05 20:30 A possible super feature to add to gcc Aspertame Man
2010-12-05 20:41 ` Basile Starynkevitch
2010-12-05 23:04 ` Joern Rennecke
@ 2010-12-06 16:44 ` Frank Ch. Eigler
2 siblings, 0 replies; 7+ messages in thread
From: Frank Ch. Eigler @ 2010-12-06 16:44 UTC (permalink / raw)
To: Aspertame Man; +Cc: gcc
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
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2010-12-06 16:44 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-12-05 20:30 A possible super feature to add to gcc Aspertame Man
2010-12-05 20:41 ` Basile Starynkevitch
2010-12-05 23:04 ` Joern Rennecke
2010-12-06 11:49 ` Aspertame Man
2010-12-06 11:52 ` Richard Kenner
2010-12-06 12:20 ` Andreas Schwab
2010-12-06 16:44 ` Frank Ch. Eigler
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).