From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20388 invoked by alias); 31 Oct 2006 15:54:45 -0000 Received: (qmail 20278 invoked by uid 48); 31 Oct 2006 15:54:28 -0000 Date: Tue, 31 Oct 2006 15:54:00 -0000 Message-ID: <20061031155428.20277.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/29649] Force core dump on runtime library errors In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2006-10/txt/msg02706.txt.bz2 List-Id: ------- 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