binutils-gdb

Tree: 09db4332c6

Commit Graph

Author	SHA1	Message	Date
Mike Frysinger	d20bc12288	gnulib: import select A few sims use this to emulate the syscall & provide network functionality.	5 years ago
Joel Brobecker	3666a04883	Update copyright year range in all GDB files 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.	6 years ago
Andrew Burgess	361cb21935	gnulib: Ensure all libraries are used when building gdb/gdbserver An issue was reported here related to building GDB on MinGW: https://sourceware.org/pipermail/gdb/2020-September/048927.html It was suggested here: https://sourceware.org/pipermail/gdb/2020-September/048931.html that the solution might be to make use of $(LIB_GETRANDOM), a variable defined in the gnulib makefile, when linking GDB. In fact I think the issue is bigger than just LIB_GETRANDOM. When using the script binutils-gdb/gnulib/update-gnulib.sh to reimport gnulib there is a lot of output from gnulib's gnulib-tool. Part of that output is this: You may need to use the following makefile variables when linking. Use them in <program>_LDADD when linking a program, or in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library. $(FREXPL_LIBM) $(FREXP_LIBM) $(INET_NTOP_LIB) $(LIBTHREAD) $(LIB_GETLOGIN) $(LIB_GETRANDOM) $(LIB_HARD_LOCALE) $(LIB_MBRTOWC) $(LIB_SETLOCALE_NULL) $(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise What I think this is telling us is that we should be including the value of all these variables on the link line for gdb and gdbserver. The problem though is that these variables are define in gnulib's makefile, but are not (necessarily) defined in GDB's makefile. One solution would be to recreate the checks that gnulib performs in order to recreate these variables in both gdb's and gdbserver's makefile. Though this shouldn't be too hard, most (if not all) of these checks are in the form macros defined in m4 files in the gnulib tree, so we could just reference these as needed. However, in this commit I propose a different solution. Currently, in the top level makefile, we give gdb and gdbserver a dependency on gnulib. Once gnulib has finished building gdb and gdbserver can start, these projects then have a hard coded (relative) path to the compiled gnulib library in their makefiles. In this commit I extend the gnulib configure script to install a new makefile fragment in the gnulib build directory. This new file will have the usual variable substitutions applied to it, and so can include the complete list (see above) of all the extra libraries that are needed when linking against gnulib. In fact the new makefile fragment defines three variables, these are: LIBGNU: The path to the archive containing gnulib. Can be used as a dependency as when this file changes gdb/gdbserver should be relinked. LIBGNU_EXTRA_LIBS: A list of linker -l.... flags that should be included in the link line of gdb/gdbserver. These are libraries that $(LIBGNU) depends on. This list is taken from the output of gnulib-tool, which is run by our gnulib/update-gnulib.sh script. INCGNU: A list of -I.... include paths that should be passed to the compiler, these are where the gnulib headers can be found. Now both gdb and gdbserver can include the makefile fragment and make use of these variables. The makefile fragment relies on the variable GNULIB_BUILDDIR being defined. This is checked for in the fragment, and was already defined in the makefiles of gdb and gdbserver. gdb/ChangeLog: * Makefile.in: Include Makefile.gnulib.inc. Don't define LIBGNU or INCGNU. Make use of LIBGNU_EXTRA_LIBS when linking. gdbserver/ChangeLog: * Makefile.in: Include Makefile.gnulib.inc. Don't define LIBGNU or INCGNU. Make use of LIBGNU_EXTRA_LIBS when linking. gnulib/ChangeLog: * Makefile.gnulib.inc.in: New file. * Makefile.in: Regenerate. * configure: Regenerate. * configure.ac: Install the new file.	6 years ago

Author

SHA1

Message

Date

Mike Frysinger

d20bc12288

gnulib: import select

A few sims use this to emulate the syscall & provide network
functionality.

5 years ago

Joel Brobecker

3666a04883

Update copyright year range in all GDB files

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.

6 years ago

Andrew Burgess

361cb21935

gnulib: Ensure all libraries are used when building gdb/gdbserver

An issue was reported here related to building GDB on MinGW:

  https://sourceware.org/pipermail/gdb/2020-September/048927.html

It was suggested here:

  https://sourceware.org/pipermail/gdb/2020-September/048931.html

that the solution might be to make use of $(LIB_GETRANDOM), a variable
defined in the gnulib makefile, when linking GDB.

In fact I think the issue is bigger than just LIB_GETRANDOM.  When
using the script binutils-gdb/gnulib/update-gnulib.sh to reimport
gnulib there is a lot of output from gnulib's gnulib-tool.  Part of
that output is this:

  You may need to use the following makefile variables when linking.
  Use them in <program>_LDADD when linking a program, or
  in <library>_a_LDFLAGS or <library>_la_LDFLAGS when linking a library.
    $(FREXPL_LIBM)
    $(FREXP_LIBM)
    $(INET_NTOP_LIB)
    $(LIBTHREAD)
    $(LIB_GETLOGIN)
    $(LIB_GETRANDOM)
    $(LIB_HARD_LOCALE)
    $(LIB_MBRTOWC)
    $(LIB_SETLOCALE_NULL)
    $(LTLIBINTL) when linking with libtool, $(LIBINTL) otherwise

What I think this is telling us is that we should be including the
value of all these variables on the link line for gdb and gdbserver.

The problem though is that these variables are define in gnulib's
makefile, but are not (necessarily) defined in GDB's makefile.

One solution would be to recreate the checks that gnulib performs in
order to recreate these variables in both gdb's and gdbserver's
makefile.  Though this shouldn't be too hard, most (if not all) of
these checks are in the form macros defined in m4 files in the gnulib
tree, so we could just reference these as needed.  However, in this
commit I propose a different solution.

Currently, in the top level makefile, we give gdb and gdbserver a
dependency on gnulib.  Once gnulib has finished building gdb and
gdbserver can start, these projects then have a hard coded (relative)
path to the compiled gnulib library in their makefiles.

In this commit I extend the gnulib configure script to install a new
makefile fragment in the gnulib build directory.  This new file will
have the usual variable substitutions applied to it, and so can
include the complete list (see above) of all the extra libraries that
are needed when linking against gnulib.

In fact the new makefile fragment defines three variables, these are:

LIBGNU: The path to the archive containing gnulib.  Can be used as a
       dependency as when this file changes gdb/gdbserver should be
       relinked.

LIBGNU_EXTRA_LIBS: A list of linker -l.... flags that should be
       included in the link line of gdb/gdbserver.  These are
       libraries that $(LIBGNU) depends on.  This list is taken from
       the output of gnulib-tool, which is run by our
       gnulib/update-gnulib.sh script.

INCGNU: A list of -I.... include paths that should be passed to the
       compiler, these are where the gnulib headers can be found.

Now both gdb and gdbserver can include the makefile fragment and make
use of these variables.

The makefile fragment relies on the variable GNULIB_BUILDDIR being
defined.  This is checked for in the fragment, and was already defined
in the makefiles of gdb and gdbserver.

gdb/ChangeLog:

	* Makefile.in: Include Makefile.gnulib.inc.  Don't define LIBGNU
	or INCGNU.  Make use of LIBGNU_EXTRA_LIBS when linking.

gdbserver/ChangeLog:

	* Makefile.in: Include Makefile.gnulib.inc.  Don't define LIBGNU
	or INCGNU.  Make use of LIBGNU_EXTRA_LIBS when linking.

gnulib/ChangeLog:

	* Makefile.gnulib.inc.in: New file.
	* Makefile.in: Regenerate.
	* configure: Regenerate.
	* configure.ac: Install the new file.

6 years ago

3 Commits (09db4332c6017ab57cd136788c48e5a81e3b9399)