Now that gdb 16.x has been added, and gdb 15.x made the default, let's
remove support for gdb 13.x.
Aside from the usual removal, we also simplify things a bit as GDB
13.x was the last version that did not require MPFR. As it is now a
mandatory dependencies, things can be simplified.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Julien Olivain <ju.o@free.fr>
Now that we have introduced support for gdb 15.x, switch to gdb 14.x
as the default version.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Romain:
- select mpfr for the target variant
- remove comment about mpfr dependency
]
Signed-off-by: Romain Naour <romain.naour@smile.fr>
As detailed in the release notes [1]:
Building GDB and GDBserver now requires a C++17 compiler (for
instance, GCC 9 or later).
Therefore, we make the option BR2_GDB_VERSION_15 depend on both
BR2_HOST_GCC_AT_LEAST_9 *and* BR2_TOOLCHAIN_GCC_AT_LEAST_9. One might
wonder why on both. It's because BR2_GDB_VERSION_15 defines both the
version of gdb used for the host *and* target, because we want them to
be in sync (to make sure our gdbserver is in sync with host-gdb).
The patches from gdb 14.1 are all ported to 15.1, with some minor
adaptation to 2 of them.
[1] https://lwn.net/Articles/981080/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Romain Naour <romain.naour@smile.fr>
All patches are still relevant, and have been rebased on top of GDB
14.1.
GDB 14.1 now needs mpfr unconditionally, so it is added as a
dependency of host-gdb, and of gdb when the full debugger is built.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- add comment about selecting mpfr for 14.x or later
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Since 3341ceb1e5 (package/gdb: zlib is mandatory, not optional), zlib
has become a mandatory dependencies of the gdb package.
However, zlib is only needed for the debugger, gdb itself, while the
server, gdbserver, does not use it.
This means that, when building an SDK to be later reused as an external
toolchain, the zlib headers and libraries are present in the sysroot of
the toolchain, tainting the toolchain and making it unsuitable to be
reused.
As Julien noticed, for example, tcl will try and link with zlib if
available, and at build time it is. But at runtime, it is not, and thus
tclsh fails to run; see 7af8dee3a8 (package/tcl: add mandatory
dependency to zlib)
When we only need to build gdbserver, we still need to configure and
build the whole gdb distribution, which means we call the top-level
configure script; that script has no option to disable the detection
of zlib: it wants to either use a system one, or it will build the
bundled one.
So, when we only build gdbserver, we tell configure to not use a system
zlib. This triggers the build of the bundled one, but it is not linked
with gdbserver so in the end it is not used on the target.
Reported-by: Julien Olivain <ju.o@free.fr>
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Cc: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
Now that gdb 13.x has been added, and 12.x made the default, follow
our usual logic of dropping the oldest gdb version: 10.x.
Only the special ARC release still needs some special handling of the
GMP dependency.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is currently no version of gdbserver for or1k. Until this
is implemented we will prevent both the direct and indirect
selection of gdbserver for or1k builds. In practice this means
that 'cross gdb for the host' cannot be selected and that
'full debugger' must be automatically selected for the gdb target
package.
This partially reverts commit 991b7b990a
which claimed that gdbserver for or1k was already supported before
version 8.3. That is not true - the commit that adds gdbserver support
for or1k [1] was only merged for version 12.1, which hasn't been
integrated in Buildroot yet.
Without that support, the build of gdbserver fails with
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: server.o: in function `main':
server.cc:(.text.startup+0x6dc): undefined reference to `initialize_low()'
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: remote-utils.o: in function `prepare_resume_reply(char*, ptid_t, target_waitstatus*)':
remote-utils.cc:(.text+0x28a8): undefined reference to `using_threads'
/home/buildroot/autobuild/instance-1/output-1/host/opt/ext-toolchain/bin/../lib/gcc/or1k-buildroot-linux-musl/11.2.0/../../../../or1k-buildroot-linux-musl/bin/ld: remote-utils.cc:(.text+0x28b0): undefined reference to `using_threads'
Fixes: http://autobuild.buildroot.net/results/b3c/b3c0df53d09d9facaf0c3c2bc4529f9fcf7737ee
[1] https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=4933265c3f71b9134363d0c05f09542d5cc677f4
Signed-off-by: Romain Naour <romain.naour@gmail.com>
Cc: Stafford Horne <shorne@gmail.com>
Signed-off-by: Arnout Vandecappelle <arnout@mind.be>
The handling of the GMP dependency needs a bit of change. Until now,
the GMP dependency was needed when building full GDB (host or target)
in version 11.x or 12.x, so we were explicitly checking whether those
versions were enabled.
Now that only GDB 10.x and the ARC-specific version of GDB are the
only remaining ones not needing GMP, we invert the logic: only those
two versions do not trigger the addition of the GMP dependency.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr: split off to its own patch]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The OpenRiSC gdb port has supported native debugging since version 8.3
and remote debugging since before that. So it is now safe to enabled
this.
This patch removes the conditions blocking gdb from being built on or1k
architecture builds.
Signed-off-by: Stafford Horne <shorne@gmail.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
The support for this architecture has been removed from the upstream
Linux kernel, as of commit:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aec499c75cf8e0b599be4d559e6922b613085f8f
Which states:
The nds32 architecture, also known as AndeStar V3, is a custom
32-bit RISC target designed by Andes Technologies. Support was added
to the kernel in 2016 as the replacement RISC-V based V5 processors
were already announced, and maintained by (current or former) Andes
employees.
As explained by Alan Kao, new customers are now all using RISC-V,
and all known nds32 users are already on longterm stable kernels
provided by Andes, with no development work going into mainline
support any more.
There has also been little to no maintenance done in Buildroot for
this architecture in recent times, so let's follow the Linux kernel
community decision and drop support for this CPU architecture.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Reviewed-by: Yu Chien Peter Lin <peterlin@andestech.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Since at least gdb 7.8, python3 support has been available. As part of
the progressive retiring of python2 support, it is time to drop its
support in gdb by:
- Removing BR2_PACKAGE_HOST_GDB_PYTHON in package/gdb/Config.in.host
and removing the choice to leave just a BR2_PACKAGE_HOST_GDB_PYTHON3
option.
- Adding BR2_PACKAGE_HOST_GDB_PYTHON to Config.in.legacy
- Changing depends on BR2_PACKAGE_PYTHON || BR2_PACKAGE_PYTHON3 to
depends on BR2_PACKAGE_PYTHON3 in package/gdb/Config.in
Signed-off-by: Adam Duskett <aduskett@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
All patch from gdb 10.2 are kept.
Starting from version 11.x, gdb needs the gmp library. The target
variant needs a bit of care: if BR2_GDB_VERSION_11 is not set, either
the host gdb is not enabled, in which case the default for the target
gdb is 9.x, or the host gdb is enabled, and another version is selected.
Signed-off-by: Michael Fischer <mf@go-sys.de>
[Thomas:
- fix how the gmp dependency is handled
- set BR2_PACKAGE_GDB_TOPLEVEL to y for gdb 11.x
- fix how BR2_GDB_VERSION is set for gdb 11.x]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[yann.morin.1998@free.fr:
- only select target gmp if using gdb 11
]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
gdb python support now uses Python3 if python3 is selected, otherwise
uses python(2) as before.
Signed-off-by: Titouan Christophe <titouan.christophe@railnova.eu>
[yann.morin.1998@free.fr: drop the gdb-python-config duplication]
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The GDB version used on ARC is based on a recent gdb code base, post
gdb 9.2. This recent gdb code base, which pre-figures what will be in
gdb 10, has a significant change: gdbserver is not longer in
gdb/gdbserver, but at the top-level, and the mechanism to build
gdbserver only has changed. Due to this change, a build of ARC GDB for
gdbserver only fails with:
/bin/bash: line 0: cd: /opt/output/build/gdb-arc-2020.03-release-gdb/gdb/gdbserver: No such file or directory
This commit adjusts gdb.mk to support four cases:
- "old" gdb, gdbserver only
- "old" gdb, with the gdb debugger (and optionally gdbserver as well)
- "new" gdb, gdbserver only
- "new" gdb, with the gdb debugger (and optionally gdbserver as well)
A boolean GDB_GDBSERVER_TOPLEVEL is introduced to differentiate
between the old and new gdb, it is set to "y" for gdb versions that
have the gdbserver code at the top-level. For now, only the ARC
version sets it, but in the future, upstream gdb version 10 will also
have to set it.
Here is the behavior, for each case:
(1) "old" gdb, gdbserver only
We set GDB_SUBDIR to gdb/gdbserver, so only the configure script
in this folder gets called.
--enable-gdbserver --disable-gdb are passed in CONF_OPTS.
(2) "old" gdb, with the gdb debugger (and optionally gdbserver as well)
We set GDB_SUBDIR to build/, an empty directory which allows to
do an out of tree build, which is mandatory for a full gdb build
since gdb 9.x.
--enable-gdb is passed in CONF_OPTS as well as --enable-gdbserver
or --disable-gdbserver depending on whether gdbserver is enabled
as well.
(3) "new" gdb, gdbserver only
We set GDB_SUBDIR to build/, an empty directory which allows to
do an out of tree build, which is mandatory for a full gdb build
since gdb 9.x.
--enable-gdbserver --disable-gdb are passed in CONF_OPTS.
(4) "new" gdb, with the gdb debugger (and optionally gdbserver as well)
We set GDB_SUBDIR to build/, an empty directory which allows to
do an out of tree build, which is mandatory for a full gdb build
since gdb 9.x.
--enable-gdb is passed in CONF_OPTS as well as --enable-gdbserver
or --disable-gdbserver depending on whether gdbserver is enabled
as well.
In addition to these changes, some related changes are done as well:
- We re-enable building both gdb and gdbserver on ARC, as it works
again.
- We only pass --with-curses when curses is really provided, i.e when
the full debugger is being built.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Tested-by: Alexey Brodkin <abrodkin@synopsys.com>
Signed-off-by: Yann E. MORIN <yann.morin.1998@free.fr>
gdb 7.12.1 was released on 21 Jan 2017 [1] and is the last version that
doesn't requires a C++11 compiler. Since Buildroot now support three other
gdb versions (8.1, 8.2 and 8.3), reduce the number of choice by dropping
7.12.1.
Remove BR2_PACKAGE_GDB_NEEDS_CXX11 symbol since it's not useful
anymore.
[1] https://lists.gnu.org/archive/html/info-gnu/2017-01/msg00009.html
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add gdb build for C-SKY Architecture:
- Support host-gdb
- Support gdbserver for target
Signed-off-by: Guo Ren <ren_guo@c-sky.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
There is currently no version of gdbserver for RISC-V. Until this
is implemented we will prevent both the direct and indirect
selection of gdbserver for RISC-V builds. In practice this means
that 'cross gdb for the host' cannot be selected and that
'full debugger' must be automatically selected for the gdb target
package.
[Peter: simplify logic, add comment]
Signed-off-by: Mark Corbin <mark.corbin@embecosm.com>
Reviewed-by: Matt Weber <matthew.weber@rockwellcollins.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Commit 1e3738db42 ("package/gdb: rework
dependency for C++11") erroneously added duplicate dependencies in
package/gdb/Config.in related to gcc 4.8 and C++ dependency.
One copy of those dependencies was below the select causing a
check-package warning.
Fixes:
package/gdb/Config.in:28: attributes order: type, default, depends on, select, help (http://nightly.buildroot.org/#_config_files)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
As we are about to switch to 8.0 as the default gdb version, we
need to adjust how the gdb dependencies are handled. Indeed, from 8.0
onwards, gdb needs a C++11 capable compiler, i.e at least gcc 4.8.
Until now, Config.in.host was making sure that gdb 8.0 was not
selectable if the cross-compilation toolchain did not have C++ support
with gcc >= 4.8. This worked fine because the default version of gdb,
used as the target gdb version when no host gdb is built, was 7.11,
and did not require C++11.
With the switch to 8.0 as the default version, when target gdb is
enabled but not host gdb, 8.0 is used, which means we need a C++11
capable compiler. The dependencies in Config.in.host are no longer
sufficient.
So instead, we remove the target-related dependencies from
Config.in.host and move them properly to Config.in. The overall logic
is the following:
- In Config.in.host, BR2_PACKAGE_HOST_GDB_ARCH_SUPPORTS ensures that
we have at least host gcc 4.8 if we're on ARC, because the ARC gdb
needs C++11. We remove the target toolchain related dependencies
from here.
- In Config.in.host, the version selection ensures that 8.0 cannot be
selected if the host toolchain does not have at least gcc 4.8. We
remove the target toolchain related dependencies from here.
- In Config.in.host, we introduce a BR2_PACKAGE_GDB_NEEDS_CXX11
option, that indicates whether the currently selected version of
gdb requires C++11 support in the toolchain to build the target
variant. Even though this option is more related to the target
variant of gdb, we keep it in Config.in.host so that it appears
next to the definition of BR2_GDB_VERSION, to make sure they are
kept in sync.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Microblaze support was never upstreamed in gdb. We currently use a gdb
from the Xilinx Github repository, but this gdb is based on 7.6, and
has never been updated in the last 4 years. There are no other active
branches at https://github.com/Xilinx/gdb/branches.
Xilinx has a slightly newer gdb, based on 7.7, available at
https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb. However,
it's apparently only available in the form of stack of big patches
(https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb/files).
Currently, gdb on Microblaze fails to build in various conditions:
* Against glibc, with "error: conflicting types for 'ps_lgetfpregs'"
* Against musl, with "error: unknown type name 'elf_gregset_t'"
While those issues can probably be fixed, the fact that there is no
active upstream significantly reduces the incentive to fix those
problems.
Therefore, let's drop support for gdb on Microblaze entirely.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Neither gdb nor gdbserver have support for ARM noMMU and OpenRISC, so
let's disable gdb on those architectures.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Changes since v2:
- Fixed BR2_openrisc to BR2_or1k in Config.in.host
Changes since v1:
- Fixed BR2_openrisc to BR2_or1k
Before adding more architecture dependencies to gdb, let's introduce a
BR2_PACKAGE_GDB_ARCH_SUPPORTS, to avoid duplicating this list of
dependencies between the Config.in comment and the main Config.in
option.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
---
Changes since v2:
- None
Changes since v1:
- None
The check-package script when ran gives warnings on ordering issues
on all of these Config files. This patch cleans up all warnings
related to the ordering in the Config files for packages starting with
the letter g in the package directory.
The appropriate ordering is: type, default, depends on, select, help
See http://nightly.buildroot.org/#_config_files for more information.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gdb arc-2016.09-rc1 is based on upstream 7.12 gdb version where we can
still disable C++ build. For more information take a look at:
https://sourceware.org/gdb/wiki/cxx-conversion
We wanted to build gdb with C++ as it is used as default in 7.12
and is even a mandatory requirement since 2016/09.
But unfortunately we missed one runtime failure that C++ build causes
and so now we have to disable C++ build.
When gdb arc-2016.09-rc1 is built as a C++ application it segfaults at
runtime for ARC.
We are going to fix the issue in 2017.03 ARC toolchain release. and
before this we remove C++ dependency are adding temporary workaround
to prevent runtime segfaults.
The workaround is to disable building gdb as C++ application via
passing --disable-build-with-cxx config option when building gdb for
ARC.
Signed-off-by: Vlad Zakharov <vzakhar@synopsys.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
gdbserver does not build on Blackfin FLAT (undefined reference to
`_td_thr_tlsbase') and while it builds on Blackfin FDPIC, it's pretty
unlikely that it is going to work properly with the cross-gdb provided
by the Analog Devices toolchain: the Analog Devices toolchain provides
a 6.6 cross-gdb, while we use gdb 7.8.2 for gdbserver.
Therefore, let's simply disable gdb completely for Blackfin.
Fixes:
http://autobuild.buildroot.org/results/2e5/2e5310d0e869f036ec70b978c62c7bd9d3d2bd70/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This commit adds a new option BR2_PACKAGE_GDB_PYTHON to enable Python
support in the target gdb. Since we can assume that the user will be
aware that Python is needed to get Python support in gdb, we chose to
use a "depends on" dependency instead of a "select" dependency.
The other weird thing is the need for a wrapper shell script to
replace gdb's provided python-config.py script. See the shell script
comment itself for all the details.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Add a configuration option to compile the gdb target package with the
--enable-tui switch.
This is done pretty much in the same way as in commit 2474fb0bf1 ("host-gdb:
enable terminal user interface support"), but for the gdb package on target.
This makes sense only when a full debugger is installed on target,
not for a gdbserver.
[Thomas: remove "default n" since this is the default, adjust the
prompt of the option, and rewrap the help text.]
Signed-off-by: Vincent Stehlé <vincent.stehle@laposte.net>
Cc: Yegor Yefremov <yegorslists@googlemail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
gdb has had AArch64 support since 7.6 which is now the default minimum
version of GDB in the tree. Older versions are now legacy.
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When a package A depends on config option B and toolchain option C, then
the comment that is given when C is not fulfilled should also depend on B.
For example:
config BR2_PACKAGE_A
depends on BR2_B
depends on BR2_LARGEFILE
depends on BR2_WCHAR
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
This comment should actually be:
comment "A needs a toolchain w/ largefile, wchar"
depends on BR2_B
depends on !BR2_LARGEFILE || !BR2_WCHAR
or if possible (typically when B is a package config option declared in that
same Config.in file):
if BR2_B
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
[other config options depending on B]
endif
Otherwise, the comment would be visible even though the other dependencies
are not met.
This patch adds such missing dependencies, and changes existing such
dependencies from
depends on BR2_BASE_DEP && !BR2_TOOLCHAIN_USES_GLIBC
to
depends on BR2_BASE_DEP
depends on !BR2_TOOLCHAIN_USES_GLIBC
so that (positive) base dependencies are separate from the (negative)
toolchain dependencies. This strategy makes it easier to write such comments
(because one can simply copy the base dependency from the actual package
config option), but also avoids complex and long boolean expressions.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch lines up the comments in Config.in files that clarify which
toolchain options the package depends on.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Thomas Petazzoni