mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-23 11:39:26 +08:00
ae6400219c
This removes a use of VEC from GDB, from dwarf2read.c. This removal is not very clean, and would probably benefit from additional refactoring in the future. The problem here is that the VEC is contained within struct dwarf2_per_cu_data, which is treated as POD in dwarf2read.c. As such it is actually a VEC pointer. When converting this to a std::vector in an ideal world we would not use a std::vector pointer, and use the std::vector directly. Sadly, to do that would require some rewriting in dwarf2read.c - my concern would be introducing bugs during this rewrite. If we move to a std::vector pointer then we need to take care to handle the case where the pointer is null. The old VEC library would handle null for us, making the VEC interface very clean. With std::vector we need to handle the null pointer case ourselves. The achieve this then I've added a small number of function that wrap up access to the std::vector, hopefully hiding the null pointer management. The final ugliness with this conversion is that, ideally, when wrapping a data member behind an interface I would make the data member private, however, treating the structure as POD once again prevents this, so we are left with the data member being public, but access (ideally) being through the published interface functions. There should be no user visible changes after this commit. gdb/ChangeLog: * gdb/dwarf2read.c (dwarf2_per_objfile::~dwarf2_per_objfile): Update for new std::vector based implementation. (process_psymtab_comp_unit_reader): Likewise. (scan_partial_symbols): Likewise. (recursively_compute_inclusions): Likewise. (compute_compunit_symtab_includes): Likewise. (process_imported_unit_die): Likewise. (queue_and_load_dwo_tu): Likewise. (follow_die_sig_1): Likewise. * gdb/dwarf2read.h: Remove DEF_VEC_P. (typedef dwarf2_per_cu_ptr): Remove. (struct dwarf2_per_cu_data) <imported_symtabs_empty>: New function. (struct dwarf2_per_cu_data) <imported_symtabs_push>: New function. (struct dwarf2_per_cu_data) <imported_symtabs_size>: New function. (struct dwarf2_per_cu_data) <imported_symtabs_free>: New function. (struct dwarf2_per_cu_data) <imported_symtabs>: Change to std::vector. Change-Id: Id0f4bda977c9dd83b0ba3d7fb42f7e5e2b6869c8
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.