From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31628 invoked by alias); 7 Aug 2008 16:56:40 -0000 Received: (qmail 31608 invoked by uid 22791); 7 Aug 2008 16:56:39 -0000 X-Spam-Check-By: sourceware.org Received: from us02smtp2.synopsys.com (HELO alvesta.synopsys.com) (198.182.60.77) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Aug 2008 16:56:01 +0000 Received: from maiden.synopsys.com (maiden.synopsys.com [146.225.100.170]) by alvesta.synopsys.com (Postfix) with ESMTP id CBFF329A0; Thu, 7 Aug 2008 09:55:58 -0700 (PDT) Received: from venkatar-opt-lnx.internal.synopsys.com (localhost [127.0.0.1]) by maiden.synopsys.com (8.9.1/8.9.1) with ESMTP id JAA28550; Thu, 7 Aug 2008 09:55:50 -0700 (PDT) Received: from venkatar-opt-lnx.internal.synopsys.com (localhost.localdomain [127.0.0.1]) by venkatar-opt-lnx.internal.synopsys.com (8.13.1/8.12.3) with ESMTP id m77GtolH002519; Thu, 7 Aug 2008 09:55:50 -0700 Received: (from jbuck@localhost) by venkatar-opt-lnx.internal.synopsys.com (8.13.1/8.13.1/Submit) id m77Gtdph002518; Thu, 7 Aug 2008 09:55:39 -0700 Date: Thu, 07 Aug 2008 16:56:00 -0000 From: Joe Buck To: Paul Koning Cc: schwab@suse.de, mark.kettenis@xs4all.nl, drow@false.org, gcc@sources.redhat.com, sposelenov@emcraft.com, gdb@sources.redhat.com Subject: Re: Problem reading corefiles on ARM Message-ID: <20080807165539.GP18206@synopsys.com> References: <20080806152736.GA31492@caradoc.them.org> <200808061542.m76FgmUv017348@brahms.sibelius.xs4all.nl> <18585.51522.726379.18666@gargle.gargle.HOWL> <20080806170912.GL18206@synopsys.com> <18585.57711.850217.939413@gargle.gargle.HOWL> <20080806175125.GM18206@synopsys.com> <18585.59545.663358.551495@gargle.gargle.HOWL> <20080806215806.GN18206@synopsys.com> <18586.63614.111756.993754@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18586.63614.111756.993754@gargle.gargle.HOWL> User-Agent: Mutt/1.4.1i Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00128.txt.bz2 Joe> After all, if we have int func1(int); void func2(int); void ordinary_function(void); void func(int arg) { int v1 = func1(arg); func2(v1); ordinary_function(); } > Joe> and there's a segfault in ordinary_function, in general v1 isn't > Joe> going to be kept around for inspection in the core dump. So why > Joe> should we impose a stricter requirement if ordinary_function is > Joe> replaced by abort() ? It seems Paul thinks we should be > Joe> required to save v1 if there's an abort call, unless I'm > Joe> misunderstanding. On Thu, Aug 07, 2008 at 09:28:30AM -0400, Paul Koning wrote: > My view is that abort() should be like other (returning) functions -- > no special treatment for variable liveness. Yes, that means in the > optimized case you may lose, some of the time. People chose -O > settings with that issue in mind. I'm not asking for more to be saved > for abort() than for regular functions -- but also no less. I'm not sure if anyone besides Paul and me care any more, but I'll just do one more. OK, consider this case: int func1(int); void func2(int); bool test(void); void func3(int); void func(int arg) { int v1 = func1(arg); func2(v1); if (test()) { func3(v1); } } Here if we put v1 in a register, we obviously have to save it across the call to test(), unless we know that test() will never return true, in which case we don't need to save v1. But what about replacing the "if" by if (!test()) abort(); func3(v1); Now, if I read you right, we'd have so save v1 even if we know that test() returns false.