binutils-gdb modified for the FreeChainXenon project
ac3d406409
GDB currently fails to build with (at least) Clang 10 and 11, due to:
$ make
CXX macroexp.o
../../src/gdb/macroexp.c:125:3: error: definition of implicit copy constructor for 'macro_buffer' is deprecated because it has a user-declared destructor [-Werror,-Wdeprecated-copy-dtor]
~macro_buffer ()
^
Now, we could just add the copy constructor, like we already have a
copy assignment operator. And like that assignment operator, we would
assert that only shared buffers can be copied from.
However, it is hard to see why only shared buffers need to be copied.
I mean, it must be true, otherwise macro support would be broken,
since currently GDB is relying on the default implementation of the
copy constructor, which just copies the fields, which can't work
correctly for the non-shared version. Still, it's not easy to tell
from the code that that is indeed correct, that there isn't some
corner case that would require copying a non-shared buffer.
Or to put it simply - the tangling of shared and non-shared buffers in
the same macro_buffer struct makes this structure hard to understand.
My reaction was -- try splitting the macro_buffer class into two
classes, one for non-shared buffers, and another for shared buffers.
Comments and asserts like these:
...
SRC must be a shared buffer; DEST must not be one. */
static void
scan (struct macro_buffer *dest,
struct macro_buffer *src,
struct macro_name_list *no_loop,
const macro_scope &scope)
{
gdb_assert (src->shared);
gdb_assert (! dest->shared);
... made me suspect it should be possible. Then after the split it
should be easier to reimplement either of the classes if we want.
So I decided to try splitting the struct in two distinct types, and
see where that leads. It turns out that there is really no good
reason for a single struct, no code that wants to work with either
shared or non-shared buffers. It's always shared for input being
parsed, and non-shared for output.
This commit is the result. I named the new classes
shared_macro_buffer and growable_macro_buffer.
A future direction could be for example to make shared_macro_buffer
wrap a string_view and growable_macro_buffer a std::string. With that
in mind, other than text/len, only the 'last_token' field is common to
both classes. I didn't feel like creating a base class just for that
single field.
I constified shared_macro_buffer's 'text' field, which of course had
some knock-on effects, fixed in the patch.
On the original warning issued by Clang -- now it is clear that only
the shared version needs to be copied. Since this class doesn't need
a user-declared destructor, the default implementations of the copy
assign/ctor can be used, and Clang no longer warns.
The growable version doesn't need to be copied, so I disabled
copy/assign for it.
gdb/ChangeLog:
* macroexp.c (struct macro_buffer): Split in two classes. Add
uses adjusted.
(struct shared_macro_buffer): New, factored out from struct
macro_buffer.
(struct growable_macro_buffer): New, factored out from struct
macro_buffer.
(set_token, get_comment, get_identifier, get_pp_number)
(get_character_constant, get_string_literal, get_punctuator)
(get_next_token_for_substitution): Constify parameters.
(substitute_args): Constify locals.
Change-Id: I5712e30e826d949715703b2e9172adf04e63b152
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| lt~obsolete.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
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.