public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Philipp Rudo <prudo@linux.vnet.ibm.com>
To: Yao Qi <qiyaoltc@gmail.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [RFC 7/7] Remove builtin tdesc_i386_*_linux
Date: Tue, 16 May 2017 12:02:00 -0000	[thread overview]
Message-ID: <20170516140228.1211aad7@ThinkPad> (raw)
In-Reply-To: <1494518105-15412-8-git-send-email-yao.qi@linaro.org>

Hi Yao,

On Thu, 11 May 2017 16:55:05 +0100
Yao Qi <qiyaoltc@gmail.com> wrote:

[...]

> diff --git a/gdb/features/i386/i386-mpx-linux.c
> b/gdb/features/i386/i386-mpx-linux.c index 9c722cf..15a1ebe 100644
> --- a/gdb/features/i386/i386-mpx-linux.c
> +++ b/gdb/features/i386/i386-mpx-linux.c
> @@ -216,25 +216,10 @@ create_feature_org_gnu_gdb_i386_mpx (struct target_desc
> *result, long regnum) }
>  #endif /* _ORG_GNU_GDB_I386_MPX */
> 
> -struct target_desc *tdesc_i386_mpx_linux;
>  static void
>  initialize_tdesc_i386_mpx_linux (void)
>  {
> -  struct target_desc *result = allocate_target_description ();
> -
> -  set_tdesc_architecture (result, bfd_scan_arch ("i386"));
> -
> -  set_tdesc_osabi (result, osabi_from_tdesc_string ("GNU/Linux"));
> -
> -  long regnum = 0;
> -
> -  regnum = create_feature_org_gnu_gdb_i386_core_i386 (result, regnum);
> -  regnum = create_feature_org_gnu_gdb_i386_sse (result, regnum);
> -  regnum = create_feature_org_gnu_gdb_i386_linux (result, regnum);
> -  regnum = create_feature_org_gnu_gdb_i386_mpx (result, regnum);
> -
> -  tdesc_i386_mpx_linux = result;
>  #if GDB_SELF_TEST
> -  selftests::record_xml_tdesc ("i386/i386-mpx-linux.xml",
> tdesc_i386_mpx_linux);
> +  selftests::record_xml ("i386/i386-mpx-linux.xml");
>  #endif /* GDB_SELF_TEST */
>  }

Do you really still need the initialize_tdesc_* functions when you initialize
the target description dynamically? Can't you move the seftest somewhere else
and get rid of it in this case?  This would make the code slightly nicer.

> diff --git a/gdb/target-descriptions.c b/gdb/target-descriptions.c
> index a81ae0d..da44e37 100644
> --- a/gdb/target-descriptions.c
> +++ b/gdb/target-descriptions.c
> @@ -2005,6 +2005,15 @@ tdesc_feature_unique_name (const struct tdesc_feature*
> feature) return name;
>  }
> 
> +/* Whether print code initializing tdesc_FUNCTION or not.  */
> +
> +static bool
> +tdesc_print_intiailize_tdesc_p (const char *function)
> +{
> +  return !(strncmp (function, "i386", 4) == 0

common/common-utils.h:startswith (function, "i386") ?

> +	   && strncmp (&function[strlen (function) - 6], "_linux", 6) == 0);

common/common-utils.h:endswith (function, "_linux") ?
(From my concat_path patch
https://sourceware.org/ml/gdb-patches/2017-03/msg00272.html)

Even nicer would be if you don't check the function name at all but check e.g.
a flag a target must set or use a feature method.  Otherwise you will get an
extremely long and unreadable expression once more targets use this method.

Philipp

> +}
> +
>  static void
>  maint_print_c_tdesc_cmd (char *args, int from_tty)
>  {
> @@ -2262,10 +2271,15 @@ maint_print_c_tdesc_cmd (char *args, int from_tty)
>        printf_unfiltered ("\n");
>      }
> 
> -  printf_unfiltered ("struct target_desc *tdesc_%s;\n", function);
> +  if (tdesc_print_intiailize_tdesc_p (function))
> +    printf_unfiltered ("struct target_desc *tdesc_%s;\n", function);
> +
>    printf_unfiltered ("static void\n");
>    printf_unfiltered ("initialize_tdesc_%s (void)\n", function);
>    printf_unfiltered ("{\n");
> +
> +  if (tdesc_print_intiailize_tdesc_p (function))
> +    {
>    printf_unfiltered
>      ("  struct target_desc *result = allocate_target_description ();\n");
> 
> @@ -2320,10 +2334,20 @@ maint_print_c_tdesc_cmd (char *args, int from_tty)
> 
>    printf_unfiltered ("\n");
>    printf_unfiltered ("  tdesc_%s = result;\n", function);
> +    }
> 
>    printf_unfiltered ("#if GDB_SELF_TEST\n");
> -  printf_unfiltered ("  selftests::record_xml_tdesc (\"%s\", tdesc_%s);\n",
> -		     filename_after_features.data (), function);
> +
> +  if (tdesc_print_intiailize_tdesc_p (function))
> +    {
> +      printf_unfiltered ("  selftests::record_xml_tdesc (\"%s\",
> tdesc_%s);\n",
> +			 filename_after_features.data (), function);
> +    }
> +  else
> +    {
> +      printf_unfiltered ("  selftests::record_xml (\"%s\");\n",
> +			 filename_after_features.data ());
> +    }
>    printf_unfiltered ("#endif /* GDB_SELF_TEST */\n");
>    printf_unfiltered ("}\n");
>  }
> @@ -2341,12 +2365,32 @@ record_xml_tdesc (std::string xml_file, const struct
> target_desc *tdesc) lists.emplace_back (xml_file, tdesc);
>  }
> 
> +/* XML files, which generate C files and compiled into GDB.  */
> +
> +static std::vector<std::string> xml_files;
> +
> +void
> +record_xml (const char *xml_file)
> +{
> +  xml_files.emplace_back (xml_file);
> +}
> +
>  /* Test these GDB builtin target descriptions are identical to these which
>     are generated by the corresponding xml files.  */
> 
>  static void
>  xml_builtin_tdesc_test (void)
>  {
> +  /* Make sure we have a test for every xml target description.  */
> +  for (auto const &xml : xml_files)
> +    {
> +      auto r = std::find_if (std::begin (lists), std::end (lists),
> +			     [&xml](decltype (lists)::const_reference e)
> +			     -> bool {return e.first == xml;});
> +
> +      SELF_CHECK (r != std::end (lists));
> +    }
> +
>    std::string feature_dir (ldirname (__FILE__));
>    struct stat st;
> 
> diff --git a/gdb/target-descriptions.h b/gdb/target-descriptions.h
> index 78416ae..2667bcd 100644
> --- a/gdb/target-descriptions.h
> +++ b/gdb/target-descriptions.h
> @@ -266,6 +266,10 @@ namespace selftests {
> 
>  void record_xml_tdesc (std::string xml_file,
>  		       const struct target_desc *tdesc);
> +
> +/* Record c file generated by XML_FILE is compiled into GDB.  */
> +
> +void record_xml (const char *xml_file);
>  }
>  #endif
> 

  reply	other threads:[~2017-05-16 12:02 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-11 15:55 [RFC 0/7] Make GDB builtin target descriptions more flexible Yao Qi
2017-05-11 15:55 ` [RFC 7/7] Remove builtin tdesc_i386_*_linux Yao Qi
2017-05-16 12:02   ` Philipp Rudo [this message]
2017-05-17 15:46   ` Pedro Alves
2017-05-11 15:55 ` [RFC 1/7] Move initialize_tdesc_mips* calls from mips-linux-nat.c to mips-linux-tdep.c Yao Qi
2017-05-11 15:55 ` [RFC 2/7] Add unit test to builtin tdesc generated by xml Yao Qi
2017-05-16 12:00   ` Philipp Rudo
2017-05-16 15:46     ` Yao Qi
2017-05-17  9:09       ` Philipp Rudo
2017-05-17 16:06     ` Pedro Alves
2017-05-30  8:00       ` Philipp Rudo
2017-06-01 17:53         ` Philipp Rudo
2017-05-17 15:41   ` Pedro Alves
2017-05-18  9:54     ` Yao Qi
2017-05-18 11:34       ` Pedro Alves
2017-05-19 15:47         ` Yao Qi
2017-05-22  8:51           ` Yao Qi
2017-05-11 15:55 ` [RFC 3/7] Adjust the order of 32bit-linux.xml and 32bit-sse.xml in i386/i386-linux.xml Yao Qi
2017-05-11 15:55 ` [RFC 6/7] Lazily and dynamically create i386-linux target descriptions Yao Qi
2017-05-11 18:14   ` John Baldwin
2017-05-11 21:03     ` Yao Qi
2017-05-17 15:43   ` Pedro Alves
2017-05-18 15:12     ` Yao Qi
2017-05-19 10:15       ` Pedro Alves
2017-05-19 14:27         ` Yao Qi
2017-05-11 15:55 ` [RFC 5/7] Centralize i386 linux " Yao Qi
2017-05-11 16:06 ` [RFC 0/7] Make GDB builtin target descriptions more flexible Eli Zaretskii
2017-05-11 20:56   ` Yao Qi
2017-05-11 20:55 ` [RFC 4/7] Share code in initialize_tdesc_ functions Yao Qi
2017-05-16 12:02   ` Philipp Rudo
2017-05-17 15:43     ` Pedro Alves
2017-05-18 11:21       ` Yao Qi

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=20170516140228.1211aad7@ThinkPad \
    --to=prudo@linux.vnet.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=qiyaoltc@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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).