[Dwarf-Discuss] Location of a returned value?

[Andrew Cagney]

True; it's typically possible; if very tedious.

This starts to breakdown though when the compiler starts looking to
violate the ABI, for instance when trying to optimize "local" function
calls (how real this is currently I don't know) or when using
alternative calling conventions.  I think, rather than rely on the
ABI, there may be an opportunity here for DWARF to describe what is
really going on.

Any way, without real code, this is somewhat theoretical.

Andrew


On Tue, Jan 6, 2009 at 4:54 PM, Jason Molenda <jmolenda at apple.com> wrote:
> For i386/x86_64 at least (the two architectures I know best) I think it's
> reasonable to expect the debugger to divine the correct behavior from the
> ABI.  If the debugger knows the function's return type from the DWARF and it
> knows the ABI, it should be able to work out what to do.  The one fly in
> this ointment on i386/x86_64 is with C++ where an object with a copy
> constructor is returned by value.  In this case, you've got a bit of a
> problem on your hands. Concretely,
>
> class f
> {
>  public:
>  int x, y;
>  f(const f&z) { x = z.x; y = z.y; }
>  f(int a, int b) { x = a; y = b; }
> };
>
> f make_f ()
> {
>  f an_f (10, 20);
>  return an_f;
> }
>
> int main ()
> {
>   f my_f = make_f();
>   return my_f.x;
> }
>
> The x86_64 ABI rules would say that a structure of two ints being returned
> uses the small-struct-return aka pcc aka in-register return convention.
>  However the C++ ABI overrides that convention in this case and the
> large-struct-return aka caller-allocated-memory convention must be used.  If
> you're stepping through main() in gdb and you call the make_f() function
> from gdb, make_f() will get a random 0th argument where it should store its
> returned structure (which may result in the program crashing) and even if it
> works, gdb won't know where to retrieve the return value from so it'll show
> you random junk.
>
> I brought this up with the dwarf committee a year or two back - I always
> thought the most natural way to handle this particular case was to decorate
> the class type die with an attribute about its special ABI-changing nature
> instead of adding information to the function die specifying how its return
> type is returned.  But I never got much interest in this suggestion; I'm
> guessing other folks aren't seeing the problem or have found other ways to
> work around it.
>
>
> J
>
>
> On Jan 6, 2009, at 7:41 AM, Andrew Cagney wrote:
>
>> Is there an ABI independent way to describe the location of a value
>> returned by a function?  For instance:
>>
>> struct ret {
>>  int i;
>>  int j;
>> }
>>
>> struct ret callee() {
>>  struct ret r = { 1, 2 };
>>  return r;
>> }
>>
>> caller() {
>>  struct ret r = callee(); // <- HERE
>>  use(&r)
>> }
>>
>> When stepping, out of callee() debuggers like to display the returned
>> value.  Traditionally, this as been implemented using ABI specific
>> code which, due to the nature of some ABIs it may not be possible to
>> determine the location of that return value even though the compiler
>> is fully aware of its location.  For instance, an ABI that passes in
>> the return value's destination as a hidden address parameter:
>>
>>   ENTER
>>   ALLOC "sizeof struct ret for r"
>>   ALLOC "sizeof struct ret for return value"
>>   PUSH "address of return value"
>>   // user does a step -over this call leaving the debugger ...
>>   CALLL caller
>>   // <- ... here
>>   MOVE "return value" to "r"
>>   PUSH "address of r"
>>   CALL use
>>   EXIT
>>   RETURN
>>
>> After the return while the compiler knows where the result has been
>> stored that information isn't always available to the debugger (other
>> than using ABI heuristics such as trusting that the result's address
>> is in a specific register).
>>
>> Several thoughts:
>>
>> - as part of the "step -over", the debugger could capture the return
>> value's address using ABI knowledge; but this may not work when
>> there's a "step -finish"
>> - the callee function's debug info could describe the return value's
>> address, if known
>> - the caller could, at the return point ("... here", above) describe
>> the returned value some how
>>
>> others?
>>
>> Andrew
>>
>>
>> One
>> _______________________________________________
>> Dwarf-Discuss mailing list
>> Dwarf-Discuss at lists.dwarfstd.org
>> http://lists.dwarfstd.org/listinfo.cgi/dwarf-discuss-dwarfstd.org
>
>