[RFC] fixing extract_struct_value_address

[RFC] fixing extract_struct_value_address

[Michael Snyder]

Problem: Find a function's return value when it is a struct 
returned by reference (thru a pointer).

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?

Re: [RFC] fixing extract_struct_value_address

[Daniel Jacobowitz]

On Wed, Aug 21, 2002 at 03:48:37PM -0700, Michael Snyder wrote:
> Problem: Find a function's return value when it is a struct 
> returned by reference (thru a pointer).
> 
> 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?

Sharing the solution to this across targets would be a good step
forward - I just had to use the same hack for another port.  You want
to be careful of functions which don't return (either GDB is activated
inside the called function and the expression is never finished, or we
longjmp out, or something...) but I believe there's somewhere that
already tries to figure these things out...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] fixing extract_struct_value_address

[Michael Snyder]

Daniel Jacobowitz wrote:
> 
> On Wed, Aug 21, 2002 at 03:48:37PM -0700, Michael Snyder wrote:
> > Problem: Find a function's return value when it is a struct
> > returned by reference (thru a pointer).
> >
> > 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?
> 
> Sharing the solution to this across targets would be a good step
> forward - I just had to use the same hack for another port.  You want
> to be careful of functions which don't return (either GDB is activated
> inside the called function and the expression is never finished, or we
> longjmp out, or something...) but I believe there's somewhere that
> already tries to figure these things out...

I've a sample implementation which I've now tested on four targets.
I'll post it tomorrow, after a little more testing.

Re: [RFC] fixing extract_struct_value_address

[Jim Blandy]

Michael Snyder <msnyder@redhat.com> writes:
> Problem: Find a function's return value when it is a struct 
> returned by reference (thru a pointer).
> 
> 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.

Doesn't this stack push and pop exactly as the generic dummy frame
stack does?  Couldn't we just add a `struct_return_addr' field to
`struct dummy_frame'?

Re: [RFC] fixing extract_struct_value_address

[Andrew Cagney]

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

Re: [RFC] fixing extract_struct_value_address

[Elena Zannoni]

Discussed before in:

http://sources.redhat.com/ml/gdb-patches/2001-11/msg00571.html
and
http://sources.redhat.com/ml/gdb-patches/2001-12/msg00325.html

never resolved.

Elena



Andrew Cagney writes:
 > > 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?
 > > 
 > 

Re: [RFC] fixing extract_struct_value_address

[Michael Snyder]

Jim Blandy wrote:
> 
> Michael Snyder <msnyder@redhat.com> writes:
> > Problem: Find a function's return value when it is a struct
> > returned by reference (thru a pointer).
> >
> > 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.
> 
> Doesn't this stack push and pop exactly as the generic dummy frame
> stack does?  Couldn't we just add a `struct_return_addr' field to
> `struct dummy_frame'?

Mmmmm, yes and no... the generic dummy frame's data structure
is not implemented as a stack -- although now that you mention
it, maybe it should be.  Functionally it may act like one...

Adding such a field to the generic dummy frame is a good idea --
but some architectures don't use the generic dummy frames.

Re: [RFC] fixing extract_struct_value_address

[Michael Snyder]

Andrew Cagney wrote:
> 
> > 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

Wouldn't that only work for targets that return the value on the stack?
Those targets already work properly (I think the 386 is one).
I'm concerned here with targets where the struct is returned
by reference (thru a pointer provided by the caller.)


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

Re: [RFC] fixing extract_struct_value_address

[Andrew Cagney]

> Adding such a field to the generic dummy frame is a good idea --
> but some architectures don't use the generic dummy frames.

That can be fixed by converting the architecture to generic dummy frames :-)

Andrew

Re: [RFC] fixing extract_struct_value_address

[Andrew Cagney]

> I get the feeling that all that is needed is for the above to be enabled
>> for all targets.
>> 
>> enjoy,
>> Andrew
> 
> 
> Wouldn't that only work for targets that return the value on the stack?
> Those targets already work properly (I think the 386 is one).
> I'm concerned here with targets where the struct is returned
> by reference (thru a pointer provided by the caller.)

See:

/* 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
  */

The comment appears to describe a situtation identical to yours.

As for the more generic problem, per:

> Discussed before in:
> 
> http://sources.redhat.com/ml/gdb-patches/2001-11/msg00571.html
> and
> http://sources.redhat.com/ml/gdb-patches/2001-12/msg00325.html
> 
> never resolved.
> 
> Elena

My understanding is that, for some ABIs, it just isn't possible to find 
the address of the returned value (unless debug info (cfi?) somehow 
helps).  For such cases, I think EXTRACT_STRUCT_VALUE_ADDRESS() should 
return zero.

enjoy,
Andrew