From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4732 invoked by alias); 7 Aug 2008 17:29:46 -0000 Received: (qmail 4716 invoked by uid 22791); 7 Aug 2008 17:29:46 -0000 X-Spam-Check-By: sourceware.org Received: from aussmtpmrkps320.us.dell.com (HELO aussmtpmrkps320.us.dell.com) (143.166.224.254) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 07 Aug 2008 17:29:07 +0000 X-IronPort-AV: E=Sophos;i="4.31,321,1215406800"; d="scan'208";a="368908016" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 07 Aug 2008 12:29:05 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18587.12411.510074.893063@gargle.gargle.HOWL> Date: Thu, 07 Aug 2008 17:29:00 -0000 From: Paul Koning To: Joe.Buck@synopsys.COM 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 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> <20080807165539.GP18206@synopsys.com> X-Mailer: VM 7.17 under 21.4 (patch 19) "Constant Variable" XEmacs Lucid X-IsSubscribed: yes 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/msg00132.txt.bz2 >>>>> "Joe" == Joe Buck writes: Joe> ...OK, consider this case: Joe> int func1(int); void func2(int); bool test(void); void Joe> func3(int); Joe> void func(int arg) { int v1 = func1(arg); func2(v1); if (test()) Joe> { func3(v1); } } Joe> Here if we put v1 in a register, we obviously have to save it Joe> across the call to test(), unless we know that test() will never Joe> return true, in which case we don't need to save v1. Joe> But what about replacing the "if" by Joe> if (!test()) abort(); func3(v1); Joe> Now, if I read you right, we'd have so save v1 even if we know Joe> that test() returns false. All I meant is "treat abort() like a regular function that returns, from the point of view of what state is saved. If in this case it means that normal GCC processing would mean "save v1" that's what it means. No special handling to save more than the usual -- but no saving less than the usual either. paul