From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23559 invoked by alias); 3 Feb 2015 22:42:19 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 23543 invoked by uid 89); 3 Feb 2015 22:42:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_SOFTFAIL,URI_HEX autolearn=no version=3.3.2 X-HELO: mwork.nabble.com Received: from mwork.nabble.com (HELO mwork.nabble.com) (162.253.133.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 03 Feb 2015 22:42:17 +0000 Received: from msam.nabble.com (unknown [162.253.133.85]) by mwork.nabble.com (Postfix) with ESMTP id E8E9612BAC2D for ; Tue, 3 Feb 2015 14:42:17 -0800 (PST) Date: Tue, 03 Feb 2015 22:42:00 -0000 From: mads_bn To: gcc@gcc.gnu.org Message-ID: <1423003336612-1117717.post@n5.nabble.com> In-Reply-To: <201110271354.26961.paul@codesourcery.com> References: <4E563F58.2060006@redhat.com> <4E5BADCC.4060809@linaro.org> <201110270215.09012.paul@codesourcery.com> <4EA918D0.3000009@redhat.com> <201110271253.14077.paul@codesourcery.com> <4EA94748.1050702@redhat.com> <201110271354.26961.paul@codesourcery.com> Subject: Re: ARM Linux EABI: unwinding through a segfault handler MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2015-02/txt/msg00026.txt.bz2 Paul, do you know of any progress on this since 2011? I cannot find any attempt to use your suggested ".personality __gnu_personality_sigframe" in prologue for "__default_sa_restorer_v2". I still need to learn more about this syntax... I'm not building the glibc myself, but can probably let a friend try it if we believe it is the right fix. We hope to be able to make some poor man's backtrace's in syslog, when fatal signals occurs in embedded systems (SIGSEGV, abort->SIGABRT etc). This was quite useful on x86 targets in the past. We are currently upgrading from EGLIBC 2.16 to 2.19 (yocto builds) and I also tried to browse the regular GLIBC head. With EGLIBC 2.16 I made a small test program and the backtrace always stopped at gsignal(), but if my signal_handler then triggered a coredump using raise(SIGQUIT) then gdb was able to backtrace beyond the signal handler (see below). http://www.eglibc.org/cgi-bin/viewvc.cgi/branches/eglibc-2_19/libc/ports/sysdeps/unix/sysv/linux/arm/sigrestorer.S?view=markup https://sourceware.org/git/?p=glibc.git;a=history;f=sysdeps/unix/sysv/linux/arm/sigrestorer.S;h=71f9e25804bedb58cb06396834e8cea05dedc191;hb=refs/heads/master arm7$ ./test # backtrace before signal raised backtrace() returned 6 addresses libdemo.so(_Z11doBacktracePKci+0x44) [0xb6f3ae38] libdemo.so(_Z2f3v+0x1c) [0xb6f3af24] libdemo.so(_Z2f2v+0x20) [0xb6f3af54] libdemo.so(_Z2f1v+0x28) [0xb6f3af8c] ./test() [0x8740] /lib/libc.so.6(__libc_start_main+0x110) [0x444b7ea8] abort # backtrace after signal raised, signal_handler dumps backtrace and raise SIGQUIT to core dump --8<-------------------- Stack --------------------8<-- Error: signal 6: libdemo.so(_ZN14doBacktraceEi+0x30)[0xb6f3b4f8] libdemo.so(_ZN14signal_handlerEi+0x134)[0xb6f3b3b4] /lib/libc.so.6(__default_sa_restorer_v2+0x0)[0x444ce1d0] /lib/libc.so.6(gsignal+0x3c)[0x444ccf28] --8<-----------------------------------------------8<-- Quit (core dumped) =========== $ gdb test core ... Program terminated with signal 3, Quit. #0 0x444ccf28 in raise () from /lib/libc.so.6 (gdb) bt #0 0x444ccf28 in raise () from /lib/libc.so.6 #1 0xb6f3b488 in signal_handler (sig=6) at mysignalhandler.cpp:176 #2 #3 0x444ccf28 in raise () from /lib/libc.so.6 #4 0x444d09a8 in abort () from /lib/libc.so.6 #5 0xb6f3afc0 in f1 () at foo.cpp:57 #6 0x00008740 in main () -- View this message in context: http://gcc.1065356.n5.nabble.com/ARM-Linux-EABI-unwinding-through-a-segfault-handler-tp692287p1117717.html Sent from the gcc - Dev mailing list archive at Nabble.com.