Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Mihail Zenkov <mihail.zenkov@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: D language support
Date: Fri, 15 Jan 2010 05:10:00 -0000	[thread overview]
Message-ID: <20100115051024.GA2786@adacore.com> (raw)
In-Reply-To: <20100113064026.14f75ff2.mihai.zenkov@gmail.com>

> It allows to call allocation of memory less often. This way chose John
> Demme. It effective way, when we need allocate many unbounded buffers
> with big size.

Are you sure this is a problem in practice? Have you made some measurement
that string allocation/deallocation for D identifiers are having
a noticeable  performance impact on GDB operations?

> But in ours case we need only on small buffer. 
> I prefer another way - just allocate one buffer with size bigger than
> worst case.

If you can prove that you can never ever exceed that worse case
scenario, then that would be fine, as long as you provide a comment
justifying this hard-coded limitation and how it was computed.
Otherwise, if some code, or some user command can lead to overflow,
however whimsical it might be, then you need to switch to a dynamic
approach.  The GNU Coding Standards explicitly warn against using
abitrary limits.

Which approach you chose is no longer important to me. The suggestions
were meant to be helpful, but it's not a huge amount of code and it's
going to be "your" maintenance problem - if any.

> 	* c-lang.c: Make c_emit_char and exp_descriptor_c public.
> 	* c-lang.h: Add declaration c_emit_char and exp_descriptor_c.

Please change the above to:

        * c-lang.c (c_emit_char, exp_descriptor_c): Make public.
        * c-lang.h (c_emit_char, exp_descriptor_c): Add declaration.

> 	* symtab.c Include d-lang.h.
                ^^^^ missing colon.

> 	* testsuite/gdb.base/default.exp: fix "set language" test.
                                         ^^^ Fix

> +static char* out_str;
> +static char* out_pos;
> +static char* mangled_str;

I prefered it when you had a type, encapsulating the whole bounded
string concept. You can always make it static if you think it helps.

If you are going to use a hard-coded limit, please use a constant
or a macro:

  #define MAX_BLA_BLA_BLA
  struct bounded_string
  {
    char buf[MAX_BLA_BLA_BLA];
    char *buf_pos;
  };

This is important, because I'm seeing "magic" constants in your code,
such as:

> +  if (size < 1024) {
> +    memcpy (out_pos, src, len);
> +    out_pos += len;

A few comments on the code above:

  . Formatting: The '{' should be on the next line.
  . No litteral constant, use MAX_BLA_BLA_BLA.
  . You do nothing when there is an overflow; This is bad, because
    this will at best lead to a mysterious error message, and at worst
    a silent malfunction.  You need to error() out.  If there is no
    valid situation where the overflow should ever happen, then
    it is internal_error() that should be called.

> +static int
> +extract_identifiers ()
                      ^^^^ (void)

> +static int
> +extract_type_info ()
                    ^^^^^ same here

> +  mangled_str = (char *) symbol;

Outch! You are bypassing the "const", preventing potentially useful
compiler warnings. Isn't there a way to avoid this?

> +  out_str = xmalloc(1024);
> +  out_pos = out_str;

If you have a static unbounded_string, you could just allocate it
once, instead of everytime to start demangling (in other words,
declare an array of char instead of a char pointer).

> +    } else if (mangled_str == strstr (mangled_str, "__Class_"))
> +      mangled_str += 8;
> +    else if (mangled_str == strstr (mangled_str, "__init_"))
> +      mangled_str += 7;
> +    else if (mangled_str == strstr (mangled_str, "__vtbl_"))
> +      mangled_str += 7;
> +    else if (mangled_str == strstr (mangled_str, "__modctor_"))
> +      mangled_str += 10;
> +    else if (mangled_str == strstr (mangled_str, "__moddtor_"))
> +      mangled_str += 10;
> +    else if (mangled_str == strstr (mangled_str, "__ModuleInfo_"))
> +      mangled_str += 13;

Use strncmp, it will be more efficient.

> +  c_printchar,		/* Print a character constant */
> +  c_printstr,		/* Function to print string constant */
> +  c_emit_char,		/* Print a single char */
> +  c_print_type,		/* Print a type using appropriate syntax */
> +  c_print_typedef,	/* Print a typedef using appropriate syntax */
> +  d_val_print,		/* Print a value using appropriate syntax */
> +  c_value_print,	/* Print a top-level value */
> +  NULL,			/* Language specific skip_trampoline */
> +  "this",		/* name_of_this */
> +  basic_lookup_symbol_nonlocal, /* lookup_symbol_nonlocal */
> +  basic_lookup_transparent_type,/* lookup_transparent_type */
> +  d_demangle,		/* Language specific symbol demangler */
> +  NULL,			/* Language specific class_name_from_physname */
> +  d_op_print_tab,	/* expression operators for printing */
> +  1,			/* c-style arrays */
> +  0,			/* String lower bound */

If you use English-style comments, then you need to start sentences
with a capital letter, and end them with a period.  For instance:

  /* Print a character constant.  */

I haven't double-checked, but I think some of us just put the name
of the struct component in the comment.  That way, someone modifying
the profile of one of these routines could simply grep of that
component name to find implementations of that routine.

> +  else if (current_language->la_language == language_d)
> +    {
> +      demangled_name = d_demangle (name, 0);
> +      if (demangled_name)
> +	{
> +	  mangled_name = name;
> +	  modified_name = demangled_name;
> +	  make_cleanup (xfree, demangled_name);
> +	}
> +    }

Can you move this back to after 'else if (lang == language_java)'?

-- 
Joel


  reply	other threads:[~2010-01-15  5:10 UTC|newest]

Thread overview: 39+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-23 23:57 Mihail Zenkov
2009-12-30 12:56 ` Joel Brobecker
2010-01-09  6:25   ` Mihail Zenkov
2010-01-09  6:29     ` Mihail Zenkov
2010-01-09 14:23       ` Joel Brobecker
2010-01-13  4:42         ` Mihail Zenkov
2010-01-15  5:10           ` Joel Brobecker [this message]
2010-01-15 21:02             ` Tom Tromey
2010-01-15 21:05           ` Tom Tromey
2010-04-14 22:22             ` Mihail Zenkov
2010-04-20 21:39               ` Tom Tromey
2010-04-21  0:01                 ` Mihail Zenkov
2010-04-21 15:57                   ` Joel Brobecker
2010-04-22  0:11                     ` Mihail Zenkov
2010-04-22  0:44                       ` Joel Brobecker
2010-04-22  1:53                         ` Mihail Zenkov
2010-04-23 18:11                           ` Tom Tromey
2010-04-24  0:06                             ` Mihail Zenkov
2010-04-27 16:05                               ` Joel Brobecker
2010-04-27 23:55                                 ` Mihail Zenkov
2010-04-28 15:17                                   ` Joel Brobecker
2010-04-28 17:11                                     ` Eli Zaretskii
2010-04-29  2:16                                     ` Mihail Zenkov
2010-04-28 17:10                                   ` Eli Zaretskii
2010-04-29  1:59                                     ` Mihail Zenkov
2010-04-29  3:10                                       ` Eli Zaretskii
2010-04-29 14:47                                       ` Joel Brobecker
2010-04-23 18:09                         ` Tom Tromey
2010-04-23 20:15                           ` Leandro Lucarella
2010-04-23 20:37                             ` Tom Tromey
2010-04-26 23:51                               ` Stan Shebs
2010-04-27  0:29                                 ` Joel Brobecker
2010-04-23 21:35               ` Robert Clipsham
2010-04-24  0:26                 ` Mihail Zenkov
2010-04-27 20:27                   ` Robert Clipsham
  -- strict thread matches above, loose matches on Subject: below --
2009-08-17 23:02 Mihail Zenkov
2009-08-18  4:18 ` Eli Zaretskii
2009-08-18 16:39 ` Tom Tromey
     [not found]   ` <20090818225844.GA9879@homero.springfield.home>
2009-08-19 18:36     ` Tom Tromey

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=20100115051024.GA2786@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sourceware.org \
    --cc=mihail.zenkov@gmail.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