From: Tom Tromey <tom@tromey.com>
To: gdb-patches@sourceware.org
Cc: Tom Tromey <tom@tromey.com>
Subject: [PATCH 1/6] Remove some manual memory management from compile interface
Date: Sun, 9 Aug 2020 07:52:53 -0600 [thread overview]
Message-ID: <20200809135258.8207-2-tom@tromey.com> (raw)
In-Reply-To: <20200809135258.8207-1-tom@tromey.com>
This changes gdb's compile code to use std::vector in a couple of
places, rather than manual memory management.
gdb/ChangeLog
2020-08-08 Tom Tromey <tom@tromey.com>
* compile/compile-cplus-types.c
(compile_cplus_convert_struct_or_union): Use std::vector.
(compile_cplus_convert_func): Likewise.
* compile/compile-c-types.c (convert_func): Use std::vector.
---
gdb/ChangeLog | 7 ++++++
gdb/compile/compile-c-types.c | 4 ++--
gdb/compile/compile-cplus-types.c | 39 +++++++++++++++----------------
3 files changed, 28 insertions(+), 22 deletions(-)
diff --git a/gdb/compile/compile-c-types.c b/gdb/compile/compile-c-types.c
index 2b25783bb00..7816ececb25 100644
--- a/gdb/compile/compile-c-types.c
+++ b/gdb/compile/compile-c-types.c
@@ -176,13 +176,13 @@ convert_func (compile_c_instance *context, struct type *type)
return_type = context->convert_type (target_type);
array.n_elements = type->num_fields ();
- array.elements = XNEWVEC (gcc_type, type->num_fields ());
+ std::vector<gcc_type> elements (array.n_elements);
+ array.elements = elements.data ();
for (i = 0; i < type->num_fields (); ++i)
array.elements[i] = context->convert_type (type->field (i).type ());
result = context->plugin ().build_function_type (return_type,
&array, is_varargs);
- xfree (array.elements);
return result;
}
diff --git a/gdb/compile/compile-cplus-types.c b/gdb/compile/compile-cplus-types.c
index 02df7ab90e6..00eaaf3fa68 100644
--- a/gdb/compile/compile-cplus-types.c
+++ b/gdb/compile/compile-cplus-types.c
@@ -848,33 +848,33 @@ compile_cplus_convert_struct_or_union (compile_cplus_instance *instance,
gcc_type result;
if (type->code () == TYPE_CODE_STRUCT)
{
- struct gcc_vbase_array bases;
int num_baseclasses = TYPE_N_BASECLASSES (type);
+ std::vector<gcc_type> elements (num_baseclasses);
+ std::vector<enum gcc_cp_symbol_kind> flags (num_baseclasses);
- memset (&bases, 0, sizeof (bases));
+ struct gcc_vbase_array bases {};
+ bases.elements = elements.data ();
if (num_baseclasses > 0)
{
- bases.elements = XNEWVEC (gcc_type, num_baseclasses);
- bases.flags = XNEWVEC (enum gcc_cp_symbol_kind, num_baseclasses);
+ bases.flags = flags.data ();
bases.n_elements = num_baseclasses;
- for (int i = 0; i < num_baseclasses; ++i)
- {
- struct type *base_type = TYPE_BASECLASS (type, i);
-
- bases.flags[i] = GCC_CP_SYMBOL_BASECLASS
- | get_field_access_flag (type, i)
- | (BASETYPE_VIA_VIRTUAL (type, i)
- ? GCC_CP_FLAG_BASECLASS_VIRTUAL
- : GCC_CP_FLAG_BASECLASS_NOFLAG);
- bases.elements[i] = instance->convert_type (base_type);
- }
+ }
+
+ for (int i = 0; i < num_baseclasses; ++i)
+ {
+ struct type *base_type = TYPE_BASECLASS (type, i);
+
+ bases.flags[i] = (GCC_CP_SYMBOL_BASECLASS
+ | get_field_access_flag (type, i)
+ | (BASETYPE_VIA_VIRTUAL (type, i)
+ ? GCC_CP_FLAG_BASECLASS_VIRTUAL
+ : GCC_CP_FLAG_BASECLASS_NOFLAG));
+ bases.elements[i] = instance->convert_type (base_type);
}
result = instance->plugin ().start_class_type
(name.get (), resuld, &bases, filename, line);
- xfree (bases.flags);
- xfree (bases.elements);
}
else
{
@@ -985,8 +985,8 @@ compile_cplus_convert_func (compile_cplus_instance *instance,
types. Those are impossible in C, though. */
gcc_type return_type = instance->convert_type (target_type);
- struct gcc_type_array array =
- { type->num_fields (), XNEWVEC (gcc_type, type->num_fields ()) };
+ std::vector<gcc_type> elements (type->num_fields ());
+ struct gcc_type_array array = { type->num_fields (), elements.data () };
int artificials = 0;
for (int i = 0; i < type->num_fields (); ++i)
{
@@ -1006,7 +1006,6 @@ compile_cplus_convert_func (compile_cplus_instance *instance,
with some minsyms like printf (compile-cplus.exp has examples). */
gcc_type result = instance->plugin ().build_function_type
(return_type, &array, is_varargs);
- xfree (array.elements);
return result;
}
--
2.17.2
next prev parent reply other threads:[~2020-08-09 13:53 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-08-09 13:52 [PATCH 0/6] Avoid manual memory management in gdb/compile/ Tom Tromey
2020-08-09 13:52 ` Tom Tromey [this message]
2020-08-09 22:34 ` [PATCH 1/6] Remove some manual memory management from compile interface Simon Marchi
2020-09-19 23:45 ` Tom Tromey
2020-09-19 23:52 ` Simon Marchi
2020-09-23 12:56 ` Tom Tromey
2020-08-09 13:52 ` [PATCH 2/6] Use new/delete for do_module_cleanup Tom Tromey
2020-08-09 22:45 ` [PP?] " Simon Marchi
2020-09-23 13:36 ` Tom Tromey
2020-08-09 13:52 ` [PATCH 3/6] Introduce and use compile_module_up Tom Tromey
2020-08-09 13:52 ` [PATCH 4/6] Transfer module ownership to do_module_cleanup Tom Tromey
2020-08-10 0:48 ` [PP?] " Simon Marchi
2020-09-23 14:55 ` Tom Tromey
2020-08-09 13:52 ` [PATCH 5/6] Simplify compile_module cleanup Tom Tromey
2020-08-09 13:52 ` [PATCH 6/6] Avoid manual memory management of argv arrays in gdb/compile 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=20200809135258.8207-2-tom@tromey.com \
--to=tom@tromey.com \
--cc=gdb-patches@sourceware.org \
/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