Re: [PATCH 2/8] infcall, c++: allow more info to be computed for pass-by-reference values

[Andrew Burgess <andrew dot burgess at embecosm dot com>]

* Aktemur, Tankut Baris <tankut.baris.aktemur@intel.com> [2019-05-31 13:53:17 +0000]:

> > > In C++, call-by-value arguments that cannot be trivially copied are
> > > implicitly passed by reference.  When making an infcall, GDB needs to
> > > find out if an argument is pass-by-reference or not, so that the correct
> > > semantics can be followed.  This patch enriches the information computed
> > > by the language ops for pass-by-reference arguments.  Instead of a plain
> > > binary result, the computed information now includes whether the
> > > argument is
> > >   - copy constructible
> > >   - destructible
> > >   - trivially copyable
> > >   - trivially copy constructible
> > >   - trivially destructible
> > > and also
> > >   - the full name of the copy constructor
> > >   - the full name of the destructor
> > > in preparation for GDB's infcall mechanism to call the copy ctor and
> > > the destructor of a pass-by-ref argument appropriately.  This
> > > information is stored in a struct named 'language_pass_by_ref_info'.
> > >
> > 
> > I have a little feedback given below, but otherwise this looks fine.
> 
> Thank you for your valuable feedback.
> 
> > > +
> > > +  /* Name of the destructor function.  Expected to be fully-qualified.  */
> > > +
> > > +  const char *dtor_name;
> > > +
> > > +  /* Is the type of the argument in question copy-constructible?  */
> > > +
> > > +  bool copy_constructible;
> > 
> > This comment doesn't seem very helpful.  Could you expand on what true
> > or false value would mean here?  I have the same question about all of
> > the fields below.
> > 
> > Also I think it might be worth inlining the default value here rather
> > than in 'default_pass_by_reference', so:
> > 
> >   bool copy_constructible = true;
> > 
> > then you can extend the comment to explain why that default was
> > selected.  I think doing this for all the fields in this struct would
> > be a good change.
> >
> > > +
> > > +  /* Is the type of the argument in question destructible?  */
> > > +
> > > +  bool destructible;
> > > +
> > > +  /* Is the argument in question trivially copyable?
> > > +     That is, is it pass-by-value?  */
> > > +
> > > +  bool trivially_copyable;
> > > +
> > > +  /* Is the argument in question trivially copy constructible?  */
> > > +
> > > +  bool trivially_copy_constructible;
> > > +
> > > +  /* Is the argument in question trivially destructible?  */
> > > +
> > > +  bool trivially_destructible;
> > > +};
> > > +
> 
> Does a definition like the one below look OK?
> 
> 
> +/* In a language (particularly C++) a function argument of an aggregate
> +   type (i.e.  class/struct/union) may be implicitly passed by reference
> +   even though it is declared a call-by-value argument in the source.
> +   The struct below puts together necessary information for GDB to be
> +   able to detect and carry out pass-by-reference semantics for a
> +   particular type.  This type is referred as T in the inlined comments
> +   below.
> +
> +   The default values of the fields are chosen to give correct semantics
> +   for primitive types and for simple aggregate types, such as
> +
> +   class T {
> +     int x;
> +   };  */
> +
> +struct language_pass_by_ref_info
> +{
> +  /* Name of the copy ctor function of T.  Expected to be
> +     fully-qualified.  */
> +  const char *cctor_name = nullptr;
> +
> +  /* Name of the destructor function of T.  Expected to be
> +     fully-qualified.  */
> +  const char *dtor_name = nullptr;
> +
> +  /* True if an argument of type T can be passed to a function by value
> +     (i.e.  not through an implicit reference).  False, otherwise.  */
> +  bool trivially_copyable = true;
> +
> +  /* True if a copy of a value of type T can be initialized by
> +     memcpy'ing the value bit-by-bit.  False, otherwise.
> +     E.g.  If T has a user-defined copy ctor, this should be false.  */
> +  bool trivially_copy_constructible = true;
> +
> +  /* True if a value of type T can be destructed simply by reclaiming
> +     the memory area occupied by the value.  False, otherwise.
> +     E.g.  If T has a user-defined destructor, this should be false.  */
> +  bool trivially_destructible = true;
> +
> +  /* True if it is allowed to create a copy of a value of type T.
> +     False, otherwise.
> +     E.g.  If T has a deleted copy ctor, this should be false.  */
> +  bool copy_constructible = true;
> +
> +  /* True if a value of type T can be destructed.  False, otherwise.
> +     E.g.  If T has a deleted destructor, this should be false.  */
> +  bool destructible = true;
> +};
> +

This looks great.

Thanks,

Andrew


> 
> Regards,
> 
> -Baris
> 
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de
> Managing Directors: Christin Eisenschmid, Gary Kershaw
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928
>