public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Ken Werner <ken@linux.vnet.ibm.com>
Cc: Tom Tromey <tromey@redhat.com>, gdb-patches@sourceware.org
Subject: Re: [patch] initial OpenCL C language support
Date: Tue, 26 Oct 2010 19:58:00 -0000	[thread overview]
Message-ID: <20101026195747.GE2847@adacore.com> (raw)
In-Reply-To: <201010261800.43899.ken@linux.vnet.ibm.com>

> 2010-10-26  Ken Werner  <ken.werner@de.ibm.com>
> 
> 	* Makefile.in (SFILES): Add opencl-lang.c.
> 	(COMMON_OBS): Add opencl-lang.o.
> 	* opencl-lang.c: New File
> 	* defs.h (enum language): Add language_opencl.
> 	* dwarf2read.c (read_file_scope): Handle DW_AT_producer for the
> 	IBM XL C OpenCL compiler.
> 	* c-lang.h: Include "parser-defs.h".
> 	(evaluate_subexp_c): Declare.
> 	* c-lang.c (evaluate_subexp_c): Remove the static qualifier.
> 	(c_op_print_tab): Add declaration.
> 	* eval.c (binop_promote): Handle language_opencl.
> 	* c-exp.y: Lookup the primitive types instead of referring to the
> 	builtins.
> 
> testsuite/ChangeLog:
> 
> 2010-10-26  Ken Werner  <ken.werner@de.ibm.com>
> 
> 	* Makefile.in (ALL_SUBDIRS): Add gdb.opencl.
> 	* configure.ac (AC_OUTPUT): Add gdb.opencl/Makefile.
> 	* configure: Regenerate.
> 	* gdb.opencl/Makefile.in: New File.
> 	* gdb.opencl/datatypes.exp: Likewise.
> 	* gdb.opencl/datatypes.cl: Likewise.
> 	* gdb.opencl/operators.exp: Likewise.
> 	* gdb.opencl/operators.cl: Likewise.
> 	* gdb.opencl/vec_comps.exp: Likewise.
> 	* gdb.opencl/vec_comps.cl: Likewise.
> 	* gdb.opencl/convs_casts.exp: Likewise.
> 	* gdb.opencl/convs_casts.cl: Likewise.
> 	* lib/opencl.exp: Likewise.
> 	* lib/opencl_hostapp.c: Likewise.
> 	* lib/opencl_kernel.cl: Likewise.
> 	* lib/cl_util.c: Likewise.
> 	* lib/cl_util.c: Likewise.
> 	* gdb.base/default.exp (set language): Add "opencl" to the list of
> 	languages.

I have a few comments, and I feel like most of the changes except maybe
the ones in c-exp.y can go in without a followup review.

> Index: src/gdb/opencl-lang.c
[...]
> +#include <string.h>
> +#include "defs.h"

The include of <string.h> directly should be replaced by an include of
"gdb_string.h". Also, the first include should always be "defs.h".

> +/* Returns the corresponding OpenCL vector type from the given type code,
> +   the length of the element type, the unsigned flag and the amount of
> +   elements (n).  */
> +static struct type *
> +lookup_opencl_vector_type (struct gdbarch *gdbarch, enum type_code code,
> +			   unsigned int el_length, unsigned int flag_unsigned,
> +			   int n)

It's really nice to see someone who documents its code.  Just a tiny nit:
Our coding style require an empty line after the comment, before the
function definition starts (there are other instances of this later,
which I did not point out).

> +/* Returns whether array contains duplicates or not within the first n number
> +   of elements.  */

Another little style nit that I'd love to see fixed in your submission,
even if I'm not personally too fussy about, is to use capital letters
when referring to function parameters.  For instance, your comment above
could be adjusted to:

> /* Returns whether the array ARR contains duplicates or not within
>    the first N elements.  */

Usually, we even write this as:

  /* Returns non-zero if the array ARR contains duplicates within
     the first N elements.  */

> +  /* The number of indicies.  */
                      "indices"
> +  /* The element indicies themselves.  */
                    ^^^^^^^^

> +  /* Assume elsize aligned offset.  */
> +  gdb_assert (offset % elsize == 0);
> +  offset /= elsize;
     ^^^^^^^^^^^^^^^^^ ????

> +  for (i = offset; i < n; i++)
> +    {
> +      struct value *from_elm_val = allocate_value (eltype);
> +      struct value *to_elm_val = value_subscript (c->val, c->indices[i]);
> +      memcpy (value_contents_writeable (from_elm_val),

Another GDB coding style rule: Empty line after local declarations...
Most of the time, you are already following that rule, but there are
a few instance where the empty line is missing.

> +  /* Multiple components of the vector are requested which means the
> +     resulting type is a vector as well.  */
> +  else
> +    {

That's just a personal comment, so feel free to follow or not: I would
move the comment inside the else block.  It would make it more obvious
that the comment only applies to that case.  And it would also avoid
slightly splitting the else part from the associated if block.

> +    case BINOP_NOTEQUAL:
> +      ret = ! value_equal (val1, val2);
              ^^^^^ extra space

> +	      /* Throw an error if arg2 or arg3 aren't vecors.  */
                                                       ^^^^^^ vectors
> +# Increase timeout
> +set timeout 60
> +verbose "Timeout set to $timeout seconds" 2

Is that really necessary? (just curious)

> +gdb_exit
> +gdb_start
> +gdb_reinitialize_dir $srcdir/$subdir
> +
> +# Load the OpenCL app
> +gdb_load ${bin}

Did you know about clean_restart? This is also documented in the testsuite
cookbook.

> +gdb_test "p sizeof(bool)" "\\\$$decimal = 4"

Small remark - the way you wrote the these tests is completely correct,
but most of us don't bother matching the $N part of the output, and
write these kinds of test as:

    gdb_test "p sizeof(bool)" " = 4"

> +gdb_run_cmd

See `Running the Example Program in GDB' in the GDB Testsuite cookbook
(http://sourceware.org/gdb/wiki/GDBTestcaseCookbook): you should add
a test that "swallows" the output from the run command.

> +/* Prints OpenCL information to stdout. */

Missing second space after the period.

> +/* Reads a given file into the memory.
> +   @param filename The file name of the file to be read
> +   @param size Returns the size of the file in bytes
> +   @return a pointer the data (NULL if the does not exist)

The style of the documentation does not follow the GDB style...

> +  /* Print OpenCL informations  */
> +  /*print_clinfo ();*/

This commented-out code should be removed.

> +  /* init data */

IWBN if we followed the GNU Coding Standards for comments, and in
particular if the sentence ended with a period.

>  	|	SHORT INT_KEYWORD
> -			{ $$ = parse_type->builtin_short; }
> +			{ $$ = lookup_signed_typename (parse_language,
> +						       parse_gdbarch,
> +						       "short"); }

Just wondering why this change is necessary (?). Can you explain a
little more?

> +extern struct value * evaluate_subexp_c (struct type *expect_type,
                       ^^ no space after the '*'

-- 
Joel

  parent reply	other threads:[~2010-10-26 19:58 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-22 17:21 Ken Werner
2010-10-25 22:41 ` Tom Tromey
2010-10-26 13:05   ` Ken Werner
2010-10-26 13:44     ` Tom Tromey
2010-10-26 16:02       ` Ken Werner
2010-10-26 17:49         ` Eli Zaretskii
2010-10-26 19:58         ` Joel Brobecker [this message]
2010-10-26 20:03           ` Joel Brobecker
2010-10-27 13:36             ` Ken Werner
2010-11-02 19:23               ` Joel Brobecker
2010-11-03 13:03                 ` Ken Werner
2010-11-03 15:27                   ` Joel Brobecker
2010-11-04 15:39                     ` Ken Werner
2010-11-04 17:48                       ` Eli Zaretskii
2010-11-05 14:21                         ` Ken Werner
2010-11-05 14:39                     ` Ken Werner
2010-10-27 19:04           ` Jan Kratochvil
2010-10-27 19:21             ` Pedro Alves
2010-10-27 21:01               ` Ken Werner
2010-11-02 16:52               ` [doc RFA] Switch to GCC coding style [Re: [patch] initial OpenCL C language support] Jan Kratochvil
2010-11-02 17:04                 ` Doug Evans
2010-11-02 17:23                   ` Jan Kratochvil
2010-11-02 17:29                     ` Doug Evans
2010-11-02 19:21                     ` Eli Zaretskii
2010-11-02 19:29                       ` Joel Brobecker
2010-11-08 12:50                       ` Jan Kratochvil
2010-11-08 16:11                         ` Joel Brobecker
2010-11-08 16:38                           ` Mark Kettenis
2010-11-08 16:43                             ` Joel Brobecker
2010-11-08 16:54                             ` Pedro Alves
2010-11-08 18:36                               ` Joel Brobecker
2010-11-02 18:01                   ` Joel Brobecker
2010-11-02 18:10                     ` [doc RFA] Switch to GCC coding style Jan Kratochvil
2010-11-02 18:20                       ` Doug Evans
2010-11-02 18:58                         ` Joel Brobecker
2010-11-02 19:19                           ` Doug Evans

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=20101026195747.GE2847@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=ken@linux.vnet.ibm.com \
    --cc=tromey@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).