From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4528 invoked by alias); 7 Aug 2008 13:30:36 -0000 Received: (qmail 4500 invoked by uid 22791); 7 Aug 2008 13:30:32 -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 13:29:53 +0000 X-IronPort-AV: E=Sophos;i="4.31,320,1215406800"; d="scan'208";a="368901142" Received: from unknown (HELO M31.equallogic.com) ([12.110.134.31]) by aussmtpmrkps320.us.dell.com with SMTP; 07 Aug 2008 08:29:51 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18586.63614.111756.993754@gargle.gargle.HOWL> Date: Thu, 07 Aug 2008 13:30: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: <4899C0FE.4010008@emcraft.com> <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> 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/msg00125.txt.bz2 >>>>> "Joe" == Joe Buck writes: Joe> Paul Koning writes: >> > That's sufficient for live debugging but not for corefiles. In >> that > case you do want caller-saved registers, because they may >> contain > local variable values that don't live in memory at the >> time of the > abort call. Joe> On Wed, Aug 06, 2008 at 11:38:14PM +0200, Andreas Schwab wrote: >> In an optimized build you can't expect any local variable to >> survive, since it may just be dead before the call, or its value >> may be unavailable for any other reason. The use of the noreturn >> attribute only adds little to this. Joe> Agreed. I think that the objective should be that if there is Joe> an abort call, then from either a core dump or when gdb'ing a Joe> live process it should be possible to determine the call site of Joe> the abort() call, even with -O2/-Os. But beyond that, the Joe> optimizer should be free, just as in other cases, to discard Joe> values in registers that will never be used again. Joe> After all, if we have Joe> int func1(int); void func2(int); void ordinary_function(void); Joe> void func(int arg) { int v1 = func1(arg); func2(v1); Joe> 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. 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. paul