From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6210 invoked by alias); 23 Nov 2004 08:33:26 -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 6130 invoked from network); 23 Nov 2004 08:33:13 -0000 Received: from unknown (HELO server7.nfra.nl) (192.87.1.57) by sourceware.org with SMTP; 23 Nov 2004 08:33:13 -0000 Received: from juw15.nfra.nl [10.87.8.15] by server7.nfra.nl; Tue, 23 Nov 2004 09:33:08 +0100 Received: from juw15.nfra.nl (localhost [127.0.0.1]) by juw15.nfra.nl (8.12.2+Sun/8.11.1) with ESMTP id iAN8X7Cu027552; Tue, 23 Nov 2004 09:33:07 +0100 (CET) Received: (from kettenis@localhost) by juw15.nfra.nl (8.12.2+Sun/8.12.2/Submit) id iAN8X6Ru027549; Tue, 23 Nov 2004 09:33:06 +0100 (CET) Date: Tue, 23 Nov 2004 08:33:00 -0000 Message-Id: <200411230833.iAN8X6Ru027549@juw15.nfra.nl> From: Mark Kettenis To: brobecker@adacore.com CC: gdb-patches@sources.redhat.com In-reply-to: <20041123053544.GM1141@adacore.com> (message from Joel Brobecker on Mon, 22 Nov 2004 21:35:44 -0800) Subject: Re: [RFA/sparc] pb doing next over struct-return function References: <20041123053544.GM1141@adacore.com> X-SW-Source: 2004-11/txt/msg00444.txt.bz2 Date: Mon, 22 Nov 2004 21:35:44 -0800 From: Joel Brobecker 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? So I made a small change to sparc32_frame_cache() to fallback to a small heuristic that should help determine whether the function is a struct-return or not based on the instruction found at "saved_pc + 8". If it is a "unimp", then for chances are the function won't return there, but one instruction later. And hence, we must have a struct-return function. This fixes the problem above, and does not introduce any regression in the testsuite. 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: +/* Return True if the instruction corresponding to PC is a "unimp" + instruction. */ Return non-zero if the instruction at PC is an "unimp" instruction. ^^^^^^^^ ^ + else + { + /* There is no debugging information for this function to + help us determine whether this function returns a struct + or not. So we rely on another heuristic which is to check + the instruction at the return address and see if this is + a "unimp" instruction. If it is, then it is struct-return + function. */ an "unimp" instruction. If it is, then it s a struct-return ^ ^ Thanks, Mark