Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@ericsson.com>
To: Pedro Alves <palves@redhat.com>,
	"gdb-patches@sourceware.org"	<gdb-patches@sourceware.org>
Subject: Re: [PATCH 2/6] invoke_xmethod & array_view
Date: Wed, 17 Oct 2018 16:21:00 -0000	[thread overview]
Message-ID: <245315f6-dd74-b533-f998-762dbf181a54@ericsson.com> (raw)
In-Reply-To: <20181015151115.6356-3-palves@redhat.com>

On 2018-10-15 11:11 a.m., Pedro Alves wrote:
> This replaces more pointer+length with gdb::array_view.  This time,
> around invoke_xmethod, and then propagating the fallout around, which
> inevitably leads to the overload resolution code.
> 
> There are several places in the code that want to grab a slice of an
> array, by advanting the array pointer, and decreasing the length

"advanting"

> pointer.  This patch introduces a pair of new
> gdb::array_view::slice(...) methods to make that convenient and clear.
> Unit test included.

Cool!

Just some minor comments.

I noticed some lines > 80 columns:

$ git show | grep ^\+ | tr '\t' '        ' | egrep '.{81}'
+      return call_xmethod (argvec[0], gdb::make_array_view (argvec + 1, nargs));
+value_user_defined_op (struct value **argp, gdb::array_view<value *> args, char *name,
+      && classify_oload_match (new_oload_champ_bv, args.size (), 0) == STANDARD)


> diff --git a/gdb/common/array-view.h b/gdb/common/array-view.h
> index 45d1a4720e..679d2e95c7 100644
> --- a/gdb/common/array-view.h
> +++ b/gdb/common/array-view.h
> @@ -169,6 +169,17 @@ public:
>    constexpr size_type size () const noexcept { return m_size; }
>    constexpr bool empty () const noexcept { return m_size == 0; }
>  
> +  /* Slice an array view.  */
> +
> +  /* Return a new array view over SIZE elements starting at START.  */
> +  constexpr array_view<T> slice (size_type start, size_t size) const noexcept
> +  { return {m_array + start, size}; }

I'm sure there's a logic for using size_type for one parameter and size_t for the other
(instead of size_type for both), but what is it?

> +
> +  /* Return a new array view over all the elements after START,
> +     inclusive.  */
> +  constexpr array_view<T> slice (size_type start) const noexcept
> +  { return {m_array + start, size () - start}; }

It would perhaps be good to have some asserts (that are only there in development
mode, maybe) to make sure we don't do stupid things, like take a slice
past the end of the array, things like that.  A bit like those asserts enabled by
__GLIBCXX_DEBUG.

> diff --git a/gdb/extension.h b/gdb/extension.h
> index 0c8c4ee934..4716d6f360 100644
> --- a/gdb/extension.h
> +++ b/gdb/extension.h
> @@ -22,6 +22,7 @@
>  
>  #include "mi/mi-cmds.h" /* For PRINT_NO_VALUES, etc.  */
>  #include "common/vec.h"
> +#include "common/array-view.h"
>  
>  struct breakpoint;
>  struct command_line;
> @@ -186,38 +187,35 @@ struct xmethod_worker
>    virtual ~xmethod_worker () = default;
>  
>    /* Invoke the xmethod encapsulated in this worker and return the result.
> -     The method is invoked on OBJ with arguments in the ARGS array.  NARGS is
> -     the length of the this array.  */
> +     The method is invoked on OBJ with arguments in the ARGS array.  */
>  
> -  virtual value *invoke (value *obj, value **args, int nargs) = 0;
> +  virtual value *invoke (value *obj, gdb::array_view<value *> args) = 0;
>  
>    /* Return the arg types of the xmethod encapsulated in this worker.
> -     An array of arg types is returned.  The length of the array is returned in
> -     NARGS.  The type of the 'this' object is returned as the first element of
> -     array.  */
> +     The type of the 'this' object is returned as the first element of
> +     the vector.  */
>  
> -  type **get_arg_types (int *nargs);
> +  std::vector<type *> get_arg_types ();
>  
>    /* Return the type of the result of the xmethod encapsulated in this worker.
> -     OBJECT, ARGS, NARGS are the same as for invoke.  */
> +     OBJECT and ARGS are the same as for invoke.  */
>  
> -  type *get_result_type (value *object, value **args, int nargs);
> +  type *get_result_type (value *object, gdb::array_view<value *> args);
>  
>  private:
>  
> -  /* Return the types of the arguments the method takes.  The number of
> -     arguments is returned in NARGS, and their types are returned in the array
> -     ARGTYPES.  */
> +  /* Return the types of the arguments the method takes.  The types
> +     are returned in TYPE_ARGS, one per argument.  */
>  
>    virtual enum ext_lang_rc do_get_arg_types
> -    (int *nargs, struct type ***arg_types) = 0;
> +    (std::vector<type *> &type_args) = 0;

Could you change this to be a pointer to the std::vector?

https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#Avoid_non-const_reference_parameters.2C_use_pointers_instead

> @@ -312,19 +312,19 @@ value_user_defined_cpp_op (struct value **args, int nargs, char *oper,
>     function, otherwise return NULL.  */
>  
>  static struct value *
> -value_user_defined_op (struct value **argp, struct value **args, char *name,
> -                       int *static_memfuncp, int nargs, enum noside noside)
> +value_user_defined_op (struct value **argp, gdb::array_view<value *> args, char *name,
> +		       int *static_memfuncp, enum noside noside)
>  {
>    struct value *result = NULL;
>  
>    if (current_language->la_language == language_cplus)
>      {
> -      result = value_user_defined_cpp_op (args, nargs, name, static_memfuncp,
> +      result = value_user_defined_cpp_op (args, name, static_memfuncp,
>  					  noside);
>      }

Maybe remove the extra braces, while touching this.

Simon

  reply	other threads:[~2018-10-17 16:21 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20181015151115.6356-1-palves@redhat.com>
2018-10-15 15:11 ` [PATCH 1/6] Use gdb:array_view in call_function_by_hand & friends Pedro Alves
2018-10-17  1:45   ` Simon Marchi
2018-11-21 12:39     ` Pedro Alves
2018-10-15 15:11 ` [PATCH 3/6] Eliminate make_symbol_overload_list-related globals & cleanup Pedro Alves
2018-10-17 17:25   ` Simon Marchi
2018-11-21 12:47     ` Pedro Alves
2018-10-15 15:11 ` [PATCH 2/6] invoke_xmethod & array_view Pedro Alves
2018-10-17 16:21   ` Simon Marchi [this message]
2018-11-21 12:47     ` Pedro Alves
2018-11-26 17:18       ` Simon Marchi
2018-11-26 17:54         ` Pedro Alves
2018-11-26 18:28           ` Simon Marchi
2018-10-15 15:11 ` [PATCH 5/6] valops.c: Some more gdb::array_view Pedro Alves
     [not found]   ` <4fcedad5-fb6a-11ed-d24f-9e9a3f6339e7@ericsson.com>
2018-11-21 12:48     ` Pedro Alves
2018-10-15 15:16 ` [PATCH 4/6] C++ify badness_vector, fix leaks Pedro Alves
     [not found]   ` <00ee88d8-857d-d85a-db78-b7a05b62ea0b@ericsson.com>
2018-11-21 12:47     ` Pedro Alves
2018-10-15 15:18 ` [PATCH 6/6] valops.c: Overload resolution code: Rename parameters/locals Pedro Alves

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=245315f6-dd74-b533-f998-762dbf181a54@ericsson.com \
    --to=simon.marchi@ericsson.com \
    --cc=gdb-patches@sourceware.org \
    --cc=palves@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