From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 784 invoked by alias); 22 Feb 2006 09:57:44 -0000 Received: (qmail 748 invoked by uid 48); 22 Feb 2006 09:57:40 -0000 Date: Wed, 22 Feb 2006 09:57:00 -0000 Message-ID: <20060222095740.747.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug other/26208] Serious problem with unwinding through signal frames In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "uweigand 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-02/txt/msg02492.txt.bz2 List-Id: ------- Comment #18 from uweigand at gcc dot gnu dot org 2006-02-22 09:57 ------- (In reply to comment #17) > (e.g. s390/linux-unwind.h was doing that, although just for 2 selected > signals, which wasn't good enough, as e.g. all async signals need to be > handled the same). We've actually taken quite a bit of care to ensure that the position of the PC on s390 can be understood deterministically in all cases. The synchronous signals come in two flavours: - SIGSEGV and SIGBUS: here the PC points back to the instruction that we attempted and failed to execute -- returning from the signal handler would by default re-execute the failed instruction - SIGILL, SIGFPE, and SIGTRAP: here the PC points after the instruction that caused the signal condition to be raised -- returning from the signal handler would by default simply continue after that instruction For all asynchronous signals, the PC points to the first instruction we have not executed yet -- returning from the signal handler thus continues execution with that instruction. So you *need* to handle signals differently depending on what signal it is -- I'm not sure I understand why you want to remove that. What we currently have definitely works correctly for all synchronous signals on s390. As for asynchronous signals, I guess it depends on what you want to see happen here -- I'm not sure what it means to throw an exception from within an asynchronous signal handler. For unwinding purposes, I guess I can see why you would want the next instruction to show up in the backtrace, so I wouldn't mind changing the if (signal == SIGBUS || signal == SIGSEGV) to if (signal != SIGILL && signal != SIGFPE && signal != SIGTRAP) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26208