From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13573 invoked by alias); 15 Jul 2004 17:40:53 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 13555 invoked from network); 15 Jul 2004 17:40:51 -0000 Received: from unknown (HELO mail-in.hq.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 15 Jul 2004 17:40:51 -0000 Received: from [192.168.11.71] (tux.hq.tensilica.com [192.168.11.71]) by mail-in.hq.tensilica.com (8.11.6/8.9.3) with ESMTP id i6FHduK18336; Thu, 15 Jul 2004 10:39:56 -0700 Message-ID: <40F6C16C.7050200@tensilica.com> Date: Thu, 15 Jul 2004 17:58:00 -0000 From: Chris Zankel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a1) Gecko/20040520 MIME-Version: 1.0 To: Daniel Jacobowitz CC: Andrew Cagney , gdb@sources.redhat.com Subject: Re: Extract the return value in finish_command on Xtensa. References: <40F31BA9.2060101@tensilica.com> <40F58BBA.5060300@gnu.org> <20040714195925.GA20006@nevyn.them.org> In-Reply-To: <20040714195925.GA20006@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2004-07/txt/msg00173.txt.bz2 Daniel Jacobowitz wrote: > On Wed, Jul 14, 2004 at 03:38:34PM -0400, Andrew Cagney wrote: > >>>I am working on a port of GDB to the Xtensa architecture. >>> >>>Unfortunately, it is impossible on Xtensa to extract the return value once >>>the 'callee' has returned to the 'caller' without analyzing the call >>>instruction (if there was one). Depending on the call instruction, the >>>return value can be in register a6, a10, oder a14. >> >>Puzzled expression. The ABI should specify which return-value >>convention will be used? >> >>I suspect you'll need to explain a little more about your architecture. What Daniel said is basically correct. Xtensa uses register windows much like Sparc but with the difference that is doesn't always shift 8 registers but a variable number of registers (4, 8, or 12). That number is encoded in the call instruction (call4, call8, or call12). The shift walue is also encoded in the return address, so the return instruction knows how many registers it has to shift backwards. The 'callee' always returns the return value in a2. For the caller the return value thus is in either a6 (call4), a10 (call8), or a14 (call12). The calling function obviously knows what call instruction it used to extract the return value. The easiest way for GDB to find the return register would be to look at the return address of the 'callee', but once that function has returned, the information is lost. Because this problem only arises for the finish command, GDB could save the return address (from the 'callee' frame) before it resumes the target and then use that value to extract the return value. Thanks, Chris