[3/6,gdb/symtab] Do more zero-initialization of type::fields
Checks
Commit Message
Now that we've introduced type::{alloc_fields,copy_fields}, the places where
no zero-initialization of allocated fields is done are easy to spot:
...
$ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false
gdb/coffread.c: type->alloc_fields (nfields, false);
gdb/coffread.c: type->alloc_fields (nsyms, false);
gdb/stabsread.c: ftype->alloc_fields (nsemi, false);
gdb/gdbtypes.c: resolved_type->alloc_fields (nfields, false);
gdb/gdbtypes.c: alloc_fields (nfields, false);
gdb/gdbtypes.c: alloc_fields (nfields, false);
gdb/mdebugread.c: t->alloc_fields (nfields, false);
gdb/mdebugread.c: ftype->alloc_fields (nparams, false);
...
All hits in gdbtypes.c are ok. There are two hits in the two variants of
copy_fields, and there's already a comment for the third.
AFAICT, the other ones are not, so fix those by dropping the "false" argument.
Tested on x86_64-linux.
---
gdb/coffread.c | 4 ++--
gdb/mdebugread.c | 4 ++--
gdb/stabsread.c | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
Comments
>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
Tom> Now that we've introduced type::{alloc_fields,copy_fields}, the places where
Tom> no zero-initialization of allocated fields is done are easy to spot:
Tom> ...
Tom> $ find gdb* -type f | grep -v ChangeLog | xargs grep alloc_fields | grep false
Tom> gdb/coffread.c: type->alloc_fields (nfields, false);
Tom> gdb/coffread.c: type->alloc_fields (nsyms, false);
Tom> gdb/stabsread.c: ftype->alloc_fields (nsemi, false);
Tom> gdb/gdbtypes.c: resolved_type->alloc_fields (nfields, false);
Tom> gdb/gdbtypes.c: alloc_fields (nfields, false);
Tom> gdb/gdbtypes.c: alloc_fields (nfields, false);
Tom> gdb/mdebugread.c: t->alloc_fields (nfields, false);
Tom> gdb/mdebugread.c: ftype->alloc_fields (nparams, false);
Tom> ...
Tom> All hits in gdbtypes.c are ok. There are two hits in the two variants of
Tom> copy_fields, and there's already a comment for the third.
Tom> AFAICT, the other ones are not, so fix those by dropping the "false" argument.
Looks good.
Approved-By: Tom Tromey <tom@tromey.com>
Honestly it probably wouldn't hurt to just always zero-init these.
If type allocation is ever a performance problem, then I suspect
something's gone pretty wrong.
Tom
@@ -2032,7 +2032,7 @@ coff_read_struct_type (int index, int length, int lastsym,
}
/* Now create the vector of fields, and record how big it is. */
- type->alloc_fields (nfields, false);
+ type->alloc_fields (nfields);
/* Copy the saved-up fields into the field vector. */
@@ -2110,7 +2110,7 @@ coff_read_enum_type (int index, int length, int lastsym,
else /* Assume ints. */
type->set_length (gdbarch_int_bit (gdbarch) / TARGET_CHAR_BIT);
type->set_code (TYPE_CODE_ENUM);
- type->alloc_fields (nsyms, false);
+ type->alloc_fields (nsyms);
/* Find the symbols for the values and put them into the type.
The symbols can be found in the symlist that we put them on
@@ -1034,7 +1034,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend,
t->set_code (type_code);
t->set_length (sh->value);
- t->alloc_fields (nfields, false);
+ t->alloc_fields (nfields);
if (type_code == TYPE_CODE_ENUM)
{
@@ -1195,7 +1195,7 @@ parse_symbol (SYMR *sh, union aux_ext *ax, char *ext_sh, int bigend,
if (nparams > 0)
{
- ftype->alloc_fields (nparams, false);
+ ftype->alloc_fields (nparams);
iparams = 0;
for (struct symbol *sym : block_iterator_range (cblock))
@@ -982,7 +982,7 @@ define_symbol (CORE_ADDR valu, const char *string, int desc, int type,
}
/* Allocate parameter information fields and fill them in. */
- ftype->alloc_fields (nsemi, false);
+ ftype->alloc_fields (nsemi);
while (*p++ == ';')
{
struct type *ptype;