OpenE2K
/
binutils-gdb
12
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
91,708 Commits 4 Branches 0 Tags 364 MiB
Commit Graph

5 Commits

Author SHA1 Message Date
Joel Brobecker 61baf725ec update copyright year range in GDB files 
This applies the second part of GDB's End of Year Procedure, which
updates the copyright year range in all of GDB's files.

gdb/ChangeLog:

        Update copyright year range in all GDB files.
 2017-01-01 10:52:34 +04:00
Joel Brobecker 618f726fcb GDB copyright headers update after running GDB's copyright.py script. 
gdb/ChangeLog:

        Update year range in copyright notice of all files.
 2016-01-01 08:43:22 +04:00
Joel Brobecker 32d0add0a6 Update year range in copyright notice of all files owned by the GDB project. 
gdb/ChangeLog:

        Update year range in copyright notice of all files.
 2015-01-01 13:32:14 +04:00
Joel Brobecker ecd75fc8ee Update Copyright year range in all files maintained by GDB. 2014-01-01 07:54:24 +04:00
Pedro Alves 17ef446eed On mainline/development, also link GDBserver with -lmcheck. 
This factors --enable-libmcheck related bits from GDB's configure.ac
and makes GDBserver use them too.  Specifically, the 'development'
global is moved to a separate script to it can be sourced by both GDB
and GDBserver, and the --enable-libmcheck/--disable-libmcheck bits
proper are moved to a new m4 file.

I started out by defining 'development' in the m4 file, but in the end
decided against it, as a separate script has the advantage that
changing it in release branches does not require regenerating
configure, unlike today.

I had also started out by making the new GDB_AC_LIBMCHECK itself
handle the yes/no default fallback depending on release/developement,
but since I had split out 'development' to a separate script, and, GDB
needs the python checks anyway (hence we'd need to do the python
checks in gdb's configure.ac, and pass in a 'default lmcheck yes/no'
parameter to GDB_AC_LIBMCHECK anyway), I ended up keeping
GDB_AC_LIBMCHECK isolated from the 'development' global.  IOW, it's
the caller's business to handle it.

Tested on x86_64 Fedora 17.  Built GDB and GDBserver with and without
--enable-libmcheck, and observed --enable-libmcheck overrides the
disablement of -lmcheck caused by python supporting threads, and that
GDBserver links with -lmcheck when expected.  Also observed that
changing the 'development' global, and issuing "make" triggers a
relink, and '-lmcheck' is included or not from the link accordingly.

gdb/
2013-07-03  Pedro Alves  <palves@redhat.com>

	* Makefile.in (config.status): Depend on development.sh.
	(aclocal_m4_deps): Add libmcheck.m4.
	* acinclude.m4: Include libmcheck.m4.
	* configure.ac: Source development.sh instead of setting
	'development' here.  --enable-libmcheck/--disable-libmcheck code
	factored out to GDB_AC_LIBMCHECK.  Run it.
	* development.sh: New file.
	* libmcheck.m4: New file.
	* configure: Regenerate.

gdb/gdbserver/
2013-07-03  Pedro Alves  <palves@redhat.com>

	* Makefile.in (config.status): Depend on development.sh.
	* acinclude.m4: Include libmcheck.m4.
	* configure: Regenerate.
 2013-07-03 13:25:46 +00:00