From: Andrew Cagney <ac131313@ges.redhat.com>
To: Michael Snyder <msnyder@redhat.com>
Cc: gdb-patches@sources.redhat.com, kevinb@redhat.com,
cagney@redhat.com, Elena Zannoni <ezannoni@redhat.com>
Subject: Re: [RFC] fixing extract_struct_value_address
Date: Thu, 22 Aug 2002 08:38:00 -0000 [thread overview]
Message-ID: <3D65001C.70609@ges.redhat.com> (raw)
In-Reply-To: <3D6418C5.FBF117D@redhat.com>
> Problem: Find a function's return value when it is a struct
> returned by reference (thru a pointer).
Hmm,
As far as I know, there are two cases:
1. a normal function forced to return:
(gdb) break foo
(gdb) finish
2. an inferior function call:
(gdb) print foo()
I don't think the first case has a solution (unless the debug info steps
forward with the answer we need).
For the latter case, the inferior function code contains:
/* Figure out the value returned by the function. */
/* elz: I defined this new macro for the hppa architecture only.
this gives us a way to get the value returned by the function from
the stack,
at the same address we told the function to put it.
We cannot assume on the pa that r28 still contains the address of
the returned
structure. Usually this will be overwritten by the callee.
I don't know about other architectures, so I defined this macro
*/
#ifdef VALUE_RETURNED_FROM_STACK
if (struct_return)
{
do_cleanups (retbuf_cleanup);
return VALUE_RETURNED_FROM_STACK (value_type, struct_addr);
}
#endif
{
struct value *retval = value_being_returned (value_type, retbuf,
struct_return);
do_cleanups (retbuf_cleanup);
return retval;
}
}
I get the feeling that all that is needed is for the above to be enabled
for all targets.
enjoy,
Andrew
> Solution level one: Take the value of the register that was
> used by the caller to pass the struct return address.
>
> Shortcoming: that register isn't preserved, so may be clobbered.
>
> Solution level two: Save the struct_return address when it
> is passed to store_struct_return (or push_arguments), and
> recover it when it is needed by extract_struct_value_address.
>
> Shortcoming: Not reentrant. Nested function calls will clobber it.
>
> Proposed solution: create a stack structure, and "push" the
> struct_return address in store_struct_return, popping it in
> extract_return_address. If you can't find it on the stack,
> then use the value of the appropriate arg0 register.
>
> I think this should work for most targets, so the code for
> managing the stack can be shared.
>
> What do you think?
>
next prev parent reply other threads:[~2002-08-22 15:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-08-21 16:05 Michael Snyder
2002-08-21 18:32 ` Daniel Jacobowitz
2002-08-21 19:04 ` Michael Snyder
2002-08-21 22:43 ` Jim Blandy
2002-08-22 11:12 ` Michael Snyder
2002-08-22 11:39 ` Andrew Cagney
2002-08-22 8:38 ` Andrew Cagney [this message]
2002-08-22 10:08 ` Elena Zannoni
2002-08-22 11:17 ` Michael Snyder
2002-08-22 13:04 ` Andrew Cagney
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=3D65001C.70609@ges.redhat.com \
--to=ac131313@ges.redhat.com \
--cc=cagney@redhat.com \
--cc=ezannoni@redhat.com \
--cc=gdb-patches@sources.redhat.com \
--cc=kevinb@redhat.com \
--cc=msnyder@redhat.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