From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21704 invoked by alias); 15 May 2008 09:13:49 -0000 Received: (qmail 21547 invoked by uid 48); 15 May 2008 09:13:09 -0000 Date: Thu, 15 May 2008 09:13:00 -0000 From: "dak at gnu dot org" To: glibc-bugs@sources.redhat.com Message-ID: <20080515091307.6522.dak@gnu.org> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug libc/6522] New: abort should not be marked noreturn X-Bugzilla-Reason: CC Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2008-05/txt/msg00038.txt.bz2 the principal raison d'etre of abort is to die with a core dump (typically on failed assertions). I am not the only person who spent days of useless post-mortem debugging (or debugging with a breakpoint on abort) because of gcc's optimization of -fcross-jumping, which means that gcc recycles a single abort call (with inconsistent stack state) all across a function. That means that the core dump has _both_ incoherent and unexpected stack state, as well as pointing to a completely wrong position in the source file. The principal purpose of the noreturn attribute is to allow for inconsistent stack state and call recycling. So its effects, if any, are directly in conflict with the purpose of abort, an unorderly exit with the main purpose to facilitate debugging. While technically abort _does_ not return, telling the compiler so is giving it leave to eradicate its call history. And that is not useful at all when debugging. Since the presence of -g should not alter the code, abort should not be marked noreturn. -- Summary: abort should not be marked noreturn Product: glibc Version: unspecified Status: NEW Severity: normal Priority: P2 Component: libc AssignedTo: drepper at redhat dot com ReportedBy: dak at gnu dot org CC: glibc-bugs at sources dot redhat dot com http://sourceware.org/bugzilla/show_bug.cgi?id=6522 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is.