Currently, when GDB loads debug information from a separate debug
file, there are a couple of warnings that could be produced if things
go wrong.
In find_separate_debug_file_by_buildid (build-id.c) GDB can give a
warning if the separate debug file doesn't include any actual debug
information, and in separate_debug_file_exists (symfile.c) we can warn
if the CRC checksum in the separate debug file doesn't match the
checksum in the original executable.
The problem here is that, when looking up debug information, GDB will
try several different approaches, lookup by build-id, lookup by
debug-link, and then a lookup from debuginfod. GDB can potentially
give a warning from an earlier attempt, and then succeed with a later
attempt. In the cases I have run into this is primarily a warning
about some out of date debug information on my machine, but then GDB
finds the correct information using debuginfod. This can be confusing
to a user, they will see warnings from GDB when really everything is
working just fine.
For example:
warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \
does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
This diagnostic was printed on Fedora 33 even when the correct
debuginfo was downloaded.
In this patch I propose that we defer any warnings related to looking
up debug information from a separate debug file. If any of the
approaches are successful then GDB will not print any of the warnings.
As far as the user is concerned, everything "just worked". Only if
GDB completely fails to find any suitable debug information will the
warnings be printed.
The crc_mismatch test compiles two executables: crc_mismatch and
crc_mismatch-2 and then strips them of debuginfo creating separate
debug files. The test then replaces crc_mismatch-2.debug with
crc_mismatch.debug to trigger "CRC mismatch" warning. A local
debuginfod server is setup to supply the correct debug file, now when
GDB looks up the debug info no warning is given.
The build-id-no-debug-warning.exp is similar to the previous test. It
triggers the "separate debug info file has no debug info" warning by
replacing the build-id based .debug file with the stripped binary and
then loading it to GDB. It then also sets up local debuginfod server
with the correct debug file to download to make sure no warnings are
emitted.
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
Currently, every internal_error call must be passed __FILE__/__LINE__
explicitly, like:
internal_error (__FILE__, __LINE__, "foo %d", var);
The need to pass in explicit __FILE__/__LINE__ is there probably
because the function predates widespread and portable variadic macros
availability. We can use variadic macros nowadays, and in fact, we
already use them in several places, including the related
gdb_assert_not_reached.
So this patch renames the internal_error function to something else,
and then reimplements internal_error as a variadic macro that expands
__FILE__/__LINE__ itself.
The result is that we now should call internal_error like so:
internal_error ("foo %d", var);
Likewise for internal_warning.
The patch adjusts all calls sites. 99% of the adjustments were done
with a perl/sed script.
The non-mechanical changes are in gdbsupport/errors.h,
gdbsupport/gdb_assert.h, and gdb/gdbarch.py.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: Ia6f372c11550ca876829e8fd85048f4502bdcf06
Add the `length` and `set_length` methods on `struct type`, in order to remove
the `TYPE_LENGTH` macro. In this patch, the macro is changed to use the
getter, so all the call sites of the macro that are used as a setter are
changed to use the setter method directly. The next patch will remove the
macro completely.
Change-Id: Id1090244f15c9856969b9be5006aefe8d8897ca4
This changes struct objfile to use a gdb_bfd_ref_ptr. In addition to
removing some manual memory management, this fixes a use-after-free
that was introduced by the registry rewrite series. The issue there
was that, in some cases, registry shutdown could refer to memory that
had already been freed. This help fix the bug by delaying the
destruction of the BFD reference (and thus the per-bfd object) until
after the registry has been shut down.
This rewrites registry.h, removing all the macros and replacing it
with relatively ordinary template classes. The result is less code
than the previous setup. It replaces large macros with a relatively
straightforward C++ class, and now manages its own cleanup.
The existing type-safe "key" class is replaced with the equivalent
template class. This approach ended up requiring relatively few
changes to the users of the registry code in gdb -- code using the key
system just required a small change to the key's declaration.
All existing users of the old C-like API are now converted to use the
type-safe API. This mostly involved changing explicit deletion
functions to be an operator() in a deleter class.
The old "save/free" two-phase process is removed, and replaced with a
single "free" phase. No existing code used both phases.
The old "free" callbacks took a parameter for the enclosing container
object. However, this wasn't truly needed and is removed here as
well.
This changes coffread.c to avoid re-reading minimal symbols when
possible. This only works when there are no COFF symbols to be read,
but at least for my mingw builds of gdb, this seems to be the case.
Tested using the AdaCore internal test suite on Windows. I also did
some local builds to ensure that no warnings crept in.
Replace with calls to blockvector::blocks, and the appropriate method
call on the returned array_view.
Change-Id: I04d1f39603e4d4c21c96822421431d9a029d8ddd
Internally we noticed that some tests would fail like so on Windows:
warning: Section .debug_aranges in [...] has duplicate debug_info_offset 0x0, ignoring .debug_aranges.
Debugging showed that, in fact, a second CU was being created at this
offset. We tracked this down to the fact that, while the ELF reader
is careful to re-use the per-BFD data, other readers are not, and
could re-read the DWARF data multiple times.
However, since the change to allow an objfile to have multiple "quick
symbol" implementations, there's no reason for this approach -- it's
safe and easy for all symbol readers to reuse the per-BFD data when
reading DWARF.
This patch implements this idea, simplifying dwarf2_build_psymtabs and
making it private, and then switching to dwarf2_initialize_objfile as
the sole way to start the DWARF reader.
Note that, while I think the call to dwarf2_build_frame_info in
machoread.c is also obsolete, I haven't attempted to remove it here.
Add a getter and a setter for a minimal symbol's type. Remove the
corresponding macro and adjust all callers.
Change-Id: I89900df5ffa5687133fe1a16b2e0d4684e67a77d
symtab::blockvector is a wrapper around compunit_symtab::blockvector.
It is a bit misleadnig, as it gives the impression that a symtab has a
blockvector. Remove it, change all users to fetch the blockvector
through the compunit instead.
Change-Id: Ibd062cd7926112a60d52899dff9224591cbdeebf
It's a bit confusing because we have both "compunit_symtab" and "symtab"
types, and many methods and functions containing "start_symtab" or
"end_symtab", which actually deal with compunit_symtabs. I believe this
comes from the time before compunit_symtab was introduced, where
symtab did the job of both.
Rename everything I found containing start_symtab or end_symtab to use
start_compunit_symtab or end_compunit_symtab.
Change-Id: If3849b156f6433640173085ad479b6a0b085ade2
Add a getter and a setter for a symbol's type. Remove the corresponding
macro and adjust all callers.
Change-Id: Ie1a137744c5bfe1df4d4f9ae5541c5299577c8de
Add a getter and a setter for whether a symbol is an argument. Remove
the corresponding macro and adjust all callers.
Change-Id: I71b4f0465f3dfd2ed8b9e140bd3f7d5eb8d9ee81
Add a getter and a setter for a symbol's domain. Remove the
corresponding macro and adjust all callers.
Change-Id: I54465b50ac89739c663859a726aef8cdc6e4b8f3
Add a getter and a setter for a symbol's aclass index. Remove the
corresponding macro and adjust all callers.
Change-Id: Ie8c8d732624cfadb714aba5ddafa3d29409b3d39
Make compunit_filetabs, used to iterate a compunit_symtab's filetabs, a
method of compunit_symtab. The name filetabs conflicts with the current
name of the field. Rename the field to m_filetabs, since at this point
nothing outside of compunit_symtab uses it, so we should treat it as
private (even though it's not actually private). Rename the
last_filetab field to m_last_filetab as well (it's only used on
compunit_symtab::add_filetab).
Adjust the COMPUNIT_FILETABS macro to keep its current behavior of
returning the first filetab.
Change-Id: I537b553a44451c52d24b18ee1bfa47e23747cfc3
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
Commit e86fc4a5bc37 ("PR 28447: implement multiple parameters for .file
on XCOFF") changes the structure associated to the internal
representation of files in COFF formats. However, gdb directory update
has been forgotten, leading to compilation errors of this kind:
CXX coffread.o
/home/simark/src/binutils-gdb/gdb/coffread.c: In function 'const char* coff_getfilename(internal_auxent*)':
/home/simark/src/binutils-gdb/gdb/coffread.c:1343:29: error: 'union internal_auxent::<unnamed struct>::<unnamed>' has no member named 'x_zeroes'
1343 | if (aux_entry->x_file.x_n.x_zeroes == 0)
| ^~~~~~~~
Fix it by adjusting the COFF code in GDB.
Change-Id: I703fa134bc722d47515efbd72b88fa5650af6c3c
Add accessors for the various location values in struct field. This
lets us assert that when we get a location value of a certain kind (say,
bitpos), the field's location indeed contains a value of that kind.
Remove the SET_FIELD_* macros, instead use the new setters directly.
Update the FIELD_* macros used to access field locations to go through
the getters. They will be removed in a subsequent patch.
There are places where the FIELD_* macros are used on call_site_target
structures, because it contains members of the same name (loc_kind and
loc). For now, I have replicated the getters/setters in
call_site_target. But we could perhaps eventually factor them in a
"location" structure that can be used at both places.
Note that the field structure, being zero-initialized, defaults to a
bitpos location with value 0. While writing this patch, I tried to make
it default to an "unset" location, to catch places where we would miss
setting a field's location. However, I found that some places relied on
the default being "bitpos 0", so I left it as-is. This change could
always be done as follow-up work, making these places explicitly set the
"bitpos 0" location.
I found two issues to fix:
- I got some failures in the gdb.base/infcall-nested-structs-c++.exp
test. They were caused by two functions in amd64-tdep.c using
TYPE_FIELD_BITPOS before checking if the location is of the bitpos
kind, which they do indirectly through `field_is_static`. Simply
move getting the bitpos below the field_is_static call.
- I got a failure in gdb.xml/tdesc-regs.exp. It turns out that in
make_gdb_type_enum, we set enum field values using SET_FIELD_BITPOS,
and later access them through FIELD_ENUMVAL. Fix that by using
set_loc_enumval to set the value.
Change-Id: I53d3734916c46457576ba11dd77df4049d2fc1e8
Add the `name` and `set_name` methods on `struct field`, in order to
remove `FIELD_NAME` and `TYPE_FIELD_NAME` macros. In this patch, the
macros are changed to use `field::name`, so all the call sites that are
used to set the field's name are changed to use `field::set_name`.
The next patch will remove the macros completely.
Note that because of the name clash between the existing field named
`name` and the new method, I renamed the field `m_name`. It is not
private per-se, because we can't make `struct field` a non-POD yet, but
it should be considered private anyway (not accessed outside `struct
field`).
Change-Id: If16ddbca4e0c39d0ff9da420bb5cdebe5b9b0896
I spotted some indentation issues where we had some spaces followed by
tabs at beginning of line, that I wanted to fix. So while at it, I did
a quick grep to find and fix all I could find.
gdb/ChangeLog:
* Fix tab after space indentation issues throughout.
Change-Id: I1acb414dd9c593b474ae2b8667496584df4316fd
Partial symbols are read via the sym_fns::sym_read_psymbols function
pointer. In order to separate the partial symbols from the objfile,
this must instead be done via a virtual method on
quick_symbol_functions. This patch implements this change.
gdb/ChangeLog
2021-03-20 Tom Tromey <tom@tromey.com>
* xcoffread.c (xcoff_sym_fns): Update.
* symfile.h (struct sym_fns) <sym_read_psymbols>: Remove.
* symfile-debug.c (objfile::has_partial_symbols): Use
can_lazily_read_symbols.
(debug_sym_read_psymbols): Remove.
(debug_sym_fns, install_symfile_debug_logging): Update.
* quick-symbol.h (struct quick_symbol_functions)
<can_lazily_read_symbols, read_partial_symbols>: New methods.
* psymtab.c (require_partial_symbols): Use new 'qf' methods.
* mipsread.c (ecoff_sym_fns): Update.
* machoread.c (macho_sym_fns): Update.
* elfread.c (struct lazy_dwarf_reader): New.
(elf_symfile_read): Update.
(read_psyms): Now a method of lazy_dwarf_reader.
(elf_sym_fns): Update.
(elf_sym_fns_lazy_psyms): Remove.
* dbxread.c (aout_sym_fns): Update.
* coffread.c (coff_sym_fns): Update.
Currently the "partial" symbol reader is attached to the objfile's
symbol functions. However, in order to allow multiple separate
partial symbol readers, this association must be changed. This patch
moves the "qf" member out of sym_fns as a step toward that goal.
gdb/ChangeLog
2021-03-20 Tom Tromey <tom@tromey.com>
* psymtab.c (require_partial_symbols): Check that 'sf' is not
null.
* xcoffread.c (xcoff_sym_fns): Update.
* symfile.h (struct sym_fns) <qf>: Remove.
* symfile.c (syms_from_objfile_1, reread_symbols): Update.
* symfile-debug.c (objfile::has_partial_symbols)
(objfile::find_last_source_symtab)
(objfile::forget_cached_source_info)
(objfile::map_symtabs_matching_filename, objfile::lookup_symbol)
(objfile::print_stats, objfile::dump)
(objfile::expand_symtabs_for_function)
(objfile::expand_all_symtabs)
(objfile::expand_symtabs_with_fullname)
(objfile::map_matching_symbols)
(objfile::expand_symtabs_matching)
(objfile::find_pc_sect_compunit_symtab)
(objfile::map_symbol_filenames)
(objfile::find_compunit_symtab_by_address)
(objfile::lookup_global_symbol_language, debug_sym_fns)
(install_symfile_debug_logging): Update.
* objfiles.h (struct objfile) <qf>: New member.
* mipsread.c (ecoff_sym_fns): Update.
* machoread.c (macho_sym_fns): Update.
* elfread.c (elf_sym_fns_gdb_index, elf_sym_fns_debug_names):
Don't declare.
(elf_symfile_read, elf_sym_fns, elf_sym_fns_lazy_psyms): Update.
* dbxread.c (aout_sym_fns): Update.
* coffread.c (coff_sym_fns): Update.
This changes objfile_has_partial_symbols to be a method on objfile.
There are some other functions that could benefit from this sort of
change, but this was the only one that was relevant to this series.
gdb/ChangeLog
2021-03-20 Tom Tromey <tom@tromey.com>
* symfile.c (read_symbols): Update.
* objfiles.h (struct objfile) <has_partial_symbols>: New method.
(objfile_has_partial_symbols): Don't declare.
* objfiles.c (objfile::has_partial_symbols): Rename from
objfile_has_partial_symbols.
(objfile_has_symbols, have_partial_symbols): Update.
* elfread.c (elf_symfile_read): Update.
* dwarf2/read.c (dwarf2_has_info): Update.
* coffread.c (coff_symfile_read): Update.
This moves some more DWARF code out of symfile.h and into a new
header, dwarf2/public.h. This header is intended to describe the
public API of the DWARF reader.
gdb/ChangeLog
2021-03-20 Tom Tromey <tom@tromey.com>
* coffread.c: Include dwarf2/public.h.
* dwarf2/frame.c: Include dwarf2/public.h.
* dwarf2/index-write.h: Include dwarf2/public.h, not symfile.h.
* dwarf2/public.h: New file.
* dwarf2/read.c: Include dwarf2/public.h.
* elfread.c: Include dwarf2/public.h.
* machoread.c: Include dwarf2/public.h.
* symfile.h (dwarf2_has_info, enum dw_index_kind)
(dwarf2_initialize_objfile, dwarf2_build_psymtabs)
(dwarf2_build_frame_info): Move to dwarf2/public.h.
* xcoffread.c: Include dwarf2/public.h.
Delete two more symbol/section related macros. This time it's
SYMBOL_SECTION and MSYMBOL_SECTION.
As with general_symbol_info::m_name it is not currently possible to
make general_symbol_info::m_section private as general_symbol_info
must remain a POD type.
But other than failing to make the new m_section private, this change
does what you'd expect, adds a get and set member function and updates
all users to use the new functions instead of the previous wrapper
macros.
There should be no user visible change after this commit.
gdb/ChangeLog:
* coff-pe-read.c (add_pe_forwarded_sym): Make use of section_index
and set_section_index member functions where appropriate.
* coffread.c (coff_symtab_read): Likewise.
(process_coff_symbol): Likewise.
* ctfread.c (set_symbol_address): Likewise.
* dwarf2/read.c (add_partial_symbol): Likewise.
(var_decode_location): Likewise.
* language.c: Likewise.
* minsyms.c (minimal_symbol_reader::record_full): Likewise.
(compact_minimal_symbols): Likewise.
(minimal_symbol_upper_bound): Likewise.
* objfiles.c (relocate_one_symbol): Likewise.
* psympriv.h (partial_symbol::obj_section): Likewise.
(partial_symbol::address): Likewise.
* psymtab.c (partial_symtab::add_psymbol): Likewise.
* stabsread.c (scan_file_globals): Likewise.
* symmisc.c (dump_msymbols): Likewise.
* symtab.c (general_symbol_info::obj_section): Likewise.
(fixup_section): Likewise.
(get_msymbol_address): Likewise.
* symtab.h (general_symbol_info::section): Rename to...
(general_symbol_info::m_section): ...this.
(general_symbol_info::set_section_index): New member function.
(general_symbol_info::section_index): Likewise.
(SYMBOL_SECTION): Delete.
(MSYMBOL_VALUE_ADDRESS): Make use of section_index and
set_section_index member functions where appropriate.
(MSYMBOL_SECTION): Delete.
(symbol::symbol): Update to initialize 'm_section'.
* xcoffread.c (read_xcoff_symtab): Make use of set_section_index.
(process_xcoff_symbol): Likewise.
When building for 32-bit ARM, I ran into a couple build failures.
The first one seems to be caused by recent changes to warning switches,
leading to the following error:
--
In file included from gdb/coffread.c:35:0:
gdb/coffread.c: In function "void enter_linenos(file_ptr, int, int, objfile*)":
gdb/complaints.h:40:40: error: format "%ld" expects argument of type "long int", but argument 2 has type "file_ptr {aka long long int}" [-Werror=format=]
complaint_internal (FMT, ##__VA_ARGS__); \
^
gdb/coffread.c:1413:7: note: in expansion of macro "complaint"
complaint (_("Line number pointer %ld lower than start of line numbers"),
^~~~~~~~~
--
The other one is due to a narrowing conversion in valops.c:
--
gdb/valops.c: In function "value* value_assign(value*, value*)":
gdb/gdbtypes.h:1798:43: error: narrowing conversion of "type->type::length" from "ULONGEST {aka long long unsigned int}" to "size_t {aka unsigned int}" inside { } [-Werror=narrowing]
#define TYPE_LENGTH(thistype) (thistype)->length
~~~~~~~~~~~~^
gdb/valops.c:1252:9: note: in expansion of macro "TYPE_LENGTH"
TYPE_LENGTH (type)});
--
Fix both with the following patch. Validated with --enable-targets=all on
Ubuntu 18.04/20.04.
gdb/ChangeLog:
2021-01-21 Luis Machado <luis.machado@linaro.org>
* coffread.c (enter_linenos): Passing string to complaint.
* valops.c (value_assign): Make array view.
This commits the result of running gdb/copyright.py as per our Start
of New Year procedure...
gdb/ChangeLog
Update copyright year range in copyright header of all GDB files.
The arguments to these functions are file_ptr, so these declarations
were accidentally implicitly down-casting them to signed int. This
allows for reading files between 2 and 4 GB in size in my testing (I
don't have a larger dll currently to test). These may not be natively
supported by Windows, but can appear when using split-dwarf information.
This solves a "can't get string table" error resulting from attempting
to pass a negative offset to bfd_seek. I encountered this occuring while
trying to use a debug file for libLLVM.dll, but searching online reveals
at least one other person may have run into a similar problem with
Firefox?
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CA+cU71k2bU0azQxjy4-77ynQj1O+TKmgtaTKe59n7Bjub1y7Tg@mail.gmail.com/
With this patch, the debug file appears to load successfully and I can
see debug information in gdb for the library.
gdb/ChangeLog:
* coffread.c (linetab_offset): Change type to file_ptr.
(linetab_size): Likewise.
(enter_linenos): Change parameter type to file_ptr.
(init_lineno): Likewise.
(init_stringtab): Likewise.
(coff_symtab_read): Likewise.
(coff_symfile_read): Change variable types to file_ptr.
Change-Id: I6ae3bf31efc51c826734ade6731ea6b1c32129f3
Add the `is_unsigned` and `set_is_unsigned` methods on `struct type`, in
order to remove the `TYPE_UNSIGNED` macro. In this patch, the
`TYPE_UNSIGNED` macro is changed to use `type::is_unsigned`, so all the
call sites that are used to set this property on a type are changed to
use the new method. The next patch will remove the macro completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <is_unsigned, set_is_unsigned>: New
methods.
(TYPE_UNSIGNED): Use type::is_unsigned. Change all write call
sites to use type::set_is_unsigned.
Change-Id: Ib09ddce84eda160a801a8f288cccf61c8ef136bc
Add the `type` and `set_type` methods on `struct field`, in order to
remoremove the `FIELD_TYPE` macro. In this patch, the `FIELD_TYPE`
macro is changed to use `field::type`, so all the call sites that are
useused to set the field's type are changed to use `field::set_type`.
The next patch will remove `FIELD_TYPE` completely.
Note that because of the name clash between the existing field named
`type` and the new method, I renamed the field `m_type`. It is not
private per-se, because we can't make `struct field` a non-POD yet, but
it should be considered private anyway (not accessed outside `struct
field`).
gdb/ChangeLog:
* gdbtypes.h (struct field) <type, set_type>: New methods.
Rename `type` field to...
<m_type>: ... this. Change references throughout to use type or
set_type methods.
(FIELD_TYPE): Use field::type. Change call sites that modify
the field's type to use field::set_type instead.
Change-Id: Ie21f866e3b7f8a51ea49b722d07d272a724459a0
Replace all uses of it by type::field.
Note that since type::field returns a reference to the field, some spots
are used to assign the whole field structure. See ctfread.c, function
attach_fields_to_type, for example. This is the same as was happening
with the macro, so I don't think it's a problem, but if anybody sees a
really nicer way to do this, now could be a good time to implement it.
gdb/ChangeLog:
* gdbtypes.h (TYPE_FIELD): Remove. Replace all uses with
type::field.
Add the `fields` and `set_fields` methods on `struct type`, in order to
remove the `TYPE_FIELDS` macro. In this patch, the `TYPE_FIELDS` macro
is changed to the `type::fields`, so all the call sites that use it to
set the fields array are changed to use `type::set_fields`. The next
patch will remove `TYPE_FIELDS` entirely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <fields, set_fields>: New methods.
(TYPE_FIELDS): Use type::fields. Change all call sites that
modify the propery to use type::set_fields instead.
Change-Id: I05174ce68f2ce3fccdf5d8b469ff141f14886b33
Remove `TYPE_NFIELDS`, changing all the call sites to use
`type::num_fields` directly. This is quite a big diff, but this was
mostly done using sed and coccinelle. A few call sites were done by
hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_NFIELDS): Remove. Change all cal sites to use
type::num_fields instead.
Change-Id: Ib73be4c36f9e770e0f729bac3b5257d7cb2f9591
Add the `num_fields` and `set_num_fields` methods on `struct type`, in
order to remove the `TYPE_NFIELDS` macro. In this patch, the
`TYPE_NFIELDS` macro is changed to use `type::num_fields`, so all the
call sites that are used to set the number of fields are changed to use
`type::set_num_fields`. The next patch will remove `TYPE_NFIELDS`
completely.
I think that in the future, we should consider making the interface of
`struct type` better. For example, right now it's possible for the
number of fields property and the actual number of fields set to be out
of sync. However, I want to keep the existing behavior in this patch,
just translate from macros to methods.
gdb/ChangeLog:
* gdbtypes.h (struct type) <num_fields, set_num_fields>: New
methods.
(TYPE_NFIELDS): Use type::num_fields. Change all call sites
that modify the number of fields to use type::set_num_fields
instead.
Change-Id: I5ad9de5be4097feaf942d111077434bf91d13dc5
I was inspired by a series of patches merged by Alan Modra in the other
projects, so I did the same in GDB with a bit of Coccinelle and grep.
This patch removes the unnecessary NULL checks before calls to xfree.
They are unnecessary because xfree already does a NULL check. Since
free is supposed to handle NULL values correctly, the NULL check in
xfree itself is also questionable, but I've left it there for now.
gdb/ChangeLog:
* coffread.c (patch_type): Remove NULL check before xfree.
* corefile.c (set_gnutarget): Likewise.
* cp-abi.c (set_cp_abi_as_auto_default): Likewise.
* exec.c (build_section_table): Likewise.
* remote.c (remote_target::pass_signals): Likewise.
* utils.c (n_spaces): Likewise.
* cli/cli-script.c (document_command): Likewise.
* i386-windows-tdep.c (core_process_module_section): Likewise.
* linux-fork.c (struct fork_info) <~fork_info>: Likewise.
Remove `TYPE_NAME`, changing all the call sites to use `type::name`
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_NAME): Remove. Change all cal sites to use
type::name instead.
Add the `name` and `set_name` methods on `struct type`, in order to
remove the `TYPE_NAME` macro. In this patch, the `TYPE_NAME` macro is
changed to use `type::name`, so all the call sites that are used to set
the type name are changed to use `type::set_name`. The next patch will
remove `TYPE_NAME` completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <name, set_name>: New methods.
(TYPE_CODE): Use type::name. Change all call sites used to set
the name to use type::set_name instead.
