This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/2] Make chained function calls in expressions work
- From: Siva Chandra <sivachandra at google dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: gdb-patches <gdb-patches at sourceware dot org>
- Date: Thu, 23 Oct 2014 08:07:43 -0700
- Subject: Re: [PATCH 0/2] Make chained function calls in expressions work
- Authentication-results: sourceware.org; auth=none
- References: <CAGyQ6gzHfLATvfUZVWzxvM+D_b=JQ2VAUoRpyAAxq6TDrYnA3Q at mail dot gmail dot com> <201410221659 dot s9MGxqM0004223 at d06av02 dot portsmouth dot uk dot ibm dot com>
I agree with everything you have said and listed. I have one last point to make.
On Wed, Oct 22, 2014 at 9:59 AM, Ulrich Weigand <uweigand@de.ibm.com> wrote:
> - Do something along the lines of your patch (with the changes already
> discussed) to preserve return value temporaries as lval_memory objects
> in those cases where they are mandated by the ABI (i.e. for types that
> have a non-trivial copy constructor or destructor).
Restricting to just those values whose address is returned in a hidden
param (per ABI) is OK, but an implementation detail made me to include
all types of return values. There are two times when a return value's
address is required:
1. When a method is invoked on the return value: GDB has to evaluate
the 'this' pointer. This is done in eval.c.
2. When the return value is in turn passed as a parameter to a
function expecting a reference: GDB has to evaluate the address of the
value and generate a TYPE_CODE_REF value from it. This logic is in
'value_arg_coerce' in infcall.c.
For objects returned in registers, having logic to create a copy on
the stack for situations like 2 is fine. However, for situations like
1, I do not think there is any way to tell whether one is dealing with
an intermediate return value or not. In which case, we are hit by the
comment at eval.c:1405. This is the reason why I have return values
returned in registers copied on to the stack in my patch. Note that,
doing a bit copy of objects returned in registers should be just fine
as they do not have non-trivial copy constructors or destructors (if
they do, then ABI says that they wont be returned in registers).
One way to get around the comment at eval.c:1405 is to make copies of
only those objects which are not_lval and which do not have
non-trivial copy-ctors or d-tors. The same thing has be to done for 2
anyway if we take this route, meaning that we change the flow in two
places (infcall.c and eval.c). If you feel that this is OK, I will
take this route. My intention was to keep the existing logic as is for
as much as possible. If we keep what I have in my patch, then we only
need to change 'value_arg_coerce' in infrun.c (and that too, only to
enable passing non-lvalue parameters to functions expecting
const-reference arguments).