From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9720 invoked by alias); 23 Nov 2004 19:29:42 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 9417 invoked from network); 23 Nov 2004 19:29:16 -0000 Received: from unknown (HELO priv-edtnes40.telusplanet.net) (199.185.220.224) by sourceware.org with SMTP; 23 Nov 2004 19:29:16 -0000 Received: from takamaka.act-europe.fr ([154.20.104.226]) by priv-edtnes40.telusplanet.net (InterMail vM.6.01.03.02 201-2131-111-104-20040324) with ESMTP id <20041123192915.RIWH27713.priv-edtnes40.telusplanet.net@takamaka.act-europe.fr>; Tue, 23 Nov 2004 12:29:15 -0700 Received: by takamaka.act-europe.fr (Postfix, from userid 507) id C035F47DA0; Tue, 23 Nov 2004 11:29:05 -0800 (PST) Date: Tue, 23 Nov 2004 19:29:00 -0000 From: Joel Brobecker To: Mark Kettenis Cc: gdb-patches@sources.redhat.com Subject: Re: [RFA/sparc] pb doing next over struct-return function Message-ID: <20041123192905.GC1215@adacore.com> References: <20041123053544.GM1141@adacore.com> <200411230833.iAN8X6Ru027549@juw15.nfra.nl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200411230833.iAN8X6Ru027549@juw15.nfra.nl> User-Agent: Mutt/1.4i X-SW-Source: 2004-11/txt/msg00452.txt.bz2 > Digging deeper, I found that this address is incorrectly computed > because cache->struct_return_p in sparc32_frame_cache() is not > set. And the reason for it not being set is that there is no > debugging information available for system__img_int__image_integer, > because it is part of the GNAT runtime, which is compiled without > debugging information. > > Just an aside, is there anything against shipping/compiling the GNAT > runtime with debug information? Yes. One of the reasons is size of debugging information. With Ada, it's pretty large. > 2004-11-22 Joel Brobecker > > * sparc-tdep.c (is_unimp_insn): New function. > (sparc32_frame_cache): For functions where there is no debugging > information to help us determine whether it's a struct-return > function or not, fallback on checking whether the instruction > at the return address is a "unimp" instruction or not. > > Makes sense to me. Could you do me a favour and rename the function > to sparc_unimp_insn_p? If you feel like it you may move it to just > after sparc_fetch_instruction, which seems a somwhat more logical > place to me (but only slightly so). Please also fix a few > spelling-mistakes in comments: Thanks. Checked in with the changes you requested (renaming the new function, moving it up, and making the spelling corrections). Although ``a "unimp" instruction" seem more natural to me, I did follow your recommendation. It's easy to change it back if it turns out one day that the use of "a" in this case is more common than the use of "an". Thanks, -- Joel