This commit converts gdb to the package infrastructure, and therefore
moves it from toolchain/gdb to package/gdb.
The target package is now visible in "Package selection for the
target" => "Debugging, profiling and benchmark". The main option,
"gdb", forcefully selects the "gdbserver" sub-option by
default. Another sub-option, "full debugger" allows to install the
complete gdb on the target. When this option is enabled, then
"gdbserver" is no longer forcefully selected. This ensures that at
least gdbserver or the full debugger gets built/installed, so that the
package is not a no-op.
The host debugger is still enabled through a configuration option in
"Toolchain". It is now visible regardless of the toolchain type (it
used to be hidden for External Toolchains). The configuration options
relative to the host debugger are now in package/gdb/Config.in.host,
similar to how we have package/binutils/Config.in.host.
Since gdb is now a proper package, it is no longer allowed to 'select
BR2_PTHREADS_DEBUG' to ensure thread debugging is available when
needed. Instead, it now 'depends on
BR2_TOOLCHAIN_HAS_THREADS_DEBUG'. This option, in turn, is selected by
the different toolchain backends when appropriate. The
'BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED' option is removed, since
we no longer need to know when it is allowed to 'select
BR2_PTHREADS_DEBUG'. Also, the 'BR2_PTHREADS_DEBUG' option is moved to
appear right below the thread implementation selection (in the case of
the Buildroot toolchain backend).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The Xtensa architecture had been removed because it required special
handling and depended on additional directories and files that became
obsolete over time. This change is more aligned to other architectures.
[Thomas: rebased on top of the "arch: improve definition of gcc mtune,
mcpu, etc." patch].
Signed-off-by: Chris Zankel <chris@zankel.net>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Our internal toolchain backend does not yet have support for AArch64,
and Crosstool-NG also does not have support for AArch64 at the moment
(though it should be coming quickly since the Linaro AArch64 toolchain
is generated with a modified Crosstool-NG version).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
While there's some microblaze support in mainline gcc from 4.6.x,
there still seems to be something missing with the uClibc support, so
disable these for now.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Newer versions of GDB need pthread debugging support if threads are
enabled, which is always the case for glibc but is a configure option
for uClibc.
We have solved this for internal toolchains by selecting the
BR2_PTHREAD_DEBUG option from the GDB selection if needed, but as this
option isn't available when ctng/external toolchains are used, mconf
prints ugly warnings and the build may fail if an external uClibc
toolchain without pthread debugging support is used.
Fix it by introducing 2 more hidden config options:
- BR2_TOOLCHAIN_HAS_THREADS_DEBUG
- BR2_TOOLCHAIN_HAS_THREADS_DEBUG_IF_NEEDED
The first tells us if the toolchain HAS pthreads debugging support,
and is checked by check_uclibc_feature in helper.mk for external uClibc
based toolchains.
The second tells us if the toolchain is ABLE TO provide pthreads debugging
support if threads are enabled, either because it's an internal toolchain
where we can force enable it or an external glibc/eglibc toolchain or
uClibc with the option enabled.
Crosstool-ng forcibly enables this support, so those will always work.
The preconfigured uClibc-based toolchains we have also all enable it.
Finally, show a comment if this isn't the case so the (external toolchain)
user knows why. This is placed outside the choice option, as menuconfig
has a bug where it doesn't show choice selections which only contain
comments.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Unfortunately, the official Blackfin toolchains are built without the
shadow password support, so our default Busybox configuration fails to
build.
Therefore, we introduce a new hidden knob
BR2_TOOLCHAIN_HAS_SHADOW_PASSWORDS, which is set to yes for Buildroot
internal toolchain, for toolchains generated by the Crosstool-NG
backend, for Glibc external toolchains and for Uclibc custom external
toolchains. It is left unset by the Blackfin toolchain profile.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Instead of letting the user define all the details of his external
toolchain, we define a set of profiles for well-known external
toolchains (CodeSourcery ones only at the moment, can easily be
extended with other toolchains).
Once a profile has been choosen, the user is offered the choice of
either letting Buildroot download and install the external toolchain,
or (as before) to tell Buildroot where the toolchain is installed on
the system.
We of course provide a "custom profile", through which the user can
configure Buildroot to use a custom external toolchain for which no
profile is available.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Handle the internal toolchain backend mechanism the
same way we handle other backends.
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Rename the external toolchain directory.
When new backends are here, it will be easier to sort them out
if they are all prefixed the same way.
Signed-off-by: Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
that the options become visible just below
the config, instead of at bottom of screen
Create a more useful default as toolchain path.
Allow generation of a script which sets up
paths to a binary toolchain generated by buildroot.
We used to use different gdb configs for internal and external toolchains
because mconf won't source the same file twice. This works, but is kind of
sub optimal, as people forget to keep them in sync.
Fix it to use the same file for both situations by shuffling around the
config options a bit. Should work identical to before (except for the newer
gdb versions available for ext).
0000047: ARM BigEndian does not allow Soft Float
When ARMEB is selected for the arch I am unable to select soft float support.
The toolchain/Config.in does not have a depend for armeb, it just has arm.
The attached patch should cover it.
