[Bug libfortran/29649] Force core dump on runtime library errors

["burnus at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #3 from burnus at gcc dot gnu dot org  2006-10-31 15:54 -------
Nice idea.


coredumping is easy, simply call "abort()" or kill(0,SIGSEGV)"
and make sure that "ulimit -c" (csh: "limit core") shows a big enough number.
This is actually what NAG f95 does and has the advantage that one can easily
investigate later. (And the stdout/stderr message can easily get be lost.)

We probably should implement this option first.
-ftrace=coredump or similar, or a envionment variable?
This is simple: Replacing the sys_exit() by if(coredump_option) abort() else
sys_exit()  in lingfortran/runtime/error.c.


Providing a trace is rather difficult, especially obtaining the symbol
information (what function in which file and which line), especially when it
should work everywhere including some strange Unix systems or MingW.

Using the glibc one can use backtrace() and backtrace_symbols() to get e.g.
./a.out [0x40088a]
/lib64/libc.so.6 [0x2b6c713bd5b0]
However, this misses the symbol information such as the name of the routine
(e.g. "main__") and especially line number and source file.

Using dlvsym one can obtain more information, but it is not part of POSIX.

Searching the internet, one can find e.g. the refdbg lib which does some
backtracing, or gdb, which of cause does it as well. Some suggest something
along the lines of "(a) got the current process' pid, (b) wrote a little gdb
command script into a /tmp file which would attach to the process, bt, and
detach, (c) ran system ("gdb --command=/tmp...") in the function, and (d)
removed the file from /tmp."


If one seriously wants to have this feature, gdb-6.5/gdb/stack.c is probably a
good starting point.

An alternative solution is to do it as g95 does: There Andy adds all needed
information to a linked list, which contains filename and line.
This does not seem to work for my example and it slows down the program, but is
easier and more portable than extracting the symbol information.

However, I'm more a fan of either coredumping (or, if someone wants to spend
the time, of creating a real strack-tracing function as the comercial compilers
[and gdb] have).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29649