Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Chris Zankel <zankel@tensilica.com>
Cc: Daniel Jacobowitz <drow@false.org>, gdb@sources.redhat.com
Subject: Re: Extract the return value in finish_command on Xtensa.
Date: Sun, 18 Jul 2004 21:49:00 -0000	[thread overview]
Message-ID: <40FAE01C.2050407@gnu.org> (raw)
In-Reply-To: <40F6C16C.7050200@tensilica.com>

Can you point us at a published abi document?

> 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.

That doesn't sound much like the sparc.  I'm wondering more about ia64. 
  Do the same feature work on that architecture.

> 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.

So the information can (with a bit of effort) be extracted from the 
calling function.  Perhaphs using prolog analysis, CFI, other registers, 
or examining the instruction.

> 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.

Your original post didn't discuss "return <value>".  That has the same 
problem as finish (except more extreem since GDB blows away the callee 
frame).

Andrew



      reply	other threads:[~2004-07-18 21:07 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-12 23:38 Chris Zankel
2004-07-14 19:40 ` Andrew Cagney
2004-07-14 20:37   ` Daniel Jacobowitz
2004-07-15 14:36     ` Andrew Cagney
2004-07-15 14:42       ` Daniel Jacobowitz
2004-07-15 17:58     ` Chris Zankel
2004-07-18 21:49       ` Andrew Cagney [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=40FAE01C.2050407@gnu.org \
    --to=cagney@gnu.org \
    --cc=drow@false.org \
    --cc=gdb@sources.redhat.com \
    --cc=zankel@tensilica.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox