Back in the day gdbserver was treated as a subproject of GDB and
even was located in "gdb/gdbserver" and so to build gdbserver we had
to go into "gdb/gdbserver" and there run configure. That way full GDB
was out of the picture.
Now starting from GDB 10.1 where gdbserver was promoted to the top-level
we're supposed to run top-level's configure script for all the tools
provided by the unified binutils-gdb tree.
That said if we only want to build gdbserver (and that's what we
want since we build one tool at a build step) we have to be explicit:
----------------->8----------------
--enable-gdbserver --disable--gdb
----------------->8----------------
Ah, and so far we used to build full native GDB when only wanted gdbserver
if it was GDB v10.x ;)
Ironically full native/target GDB also enabled gdbserver by default so
we need to also disable it explicitly with "--disable-gdbserver".
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
Since we have curses built for target anyway now, why don't allow
users to use very convenient pseudo-GUI operating mode?
And while at it, there's no use of TUI in naturally headless gdbserver.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
In GDB 10.x gdbserver was promoted to the top-level folder,
see https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=919adfe8409211c726c1d05b47ca59890ee648f1
Which means it is no longer a subfolder in "gdb" and so we have to
build gdbserver now exactly in the same way as normal native GDB.
One interesting detail is gdbserver doesn't need to deal with target
description in .xml so it doesn't depend on libexpat on target,
thus we need to move libexpat explicit selection from do_gdb_backend()
to its callers when building native [full] gdb as well as cross-gdb
for the host.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
[cp: support old/new layout, regenerate patches]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Some really old GDB releases did have gdbserver's configure
script w/o execution permissions, so there was a need in the fix.
As per Yann most likely it could have been true for GDB versions in
between v5.3 & 6.6. Moreover it could have been fixed on re-release
of GDB tarballs done in 2011, see [1].
And given we no longer support such old GDB versions in CT-NG
(as of today we have 6.8 - 9.2, moreover it's not clear which of
6.8-7.x versions are still being actively used) we'll revert that old hack
for now in a hope that it won't hurt anybody.
Though if somebody sees that problem again
we'll be able to revert this again ;)
[1] https://sourceware.org/legacy-ml/gdb/2011-09/msg00002.html
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
This commit updates the GDB build script to specify `-static-libgcc`
when `CT_GDB_NATIVE_STATIC_LIBSTDCXX` is enabled. Both libgcc and
libstdc++ are considered to be part of the "standard libraries," and
should be specified by the same flag (the configuration symbol could
potentially use a better name and/or further indirection).
This also semantically aligns the `CT_GDB_NATIVE_STATIC_LIBSTDCXX`
with the equivalent GCC configuration `CT_CC_GCC_STATIC_LIBSTDCXX`,
which also enables static linking of both libgcc and libstdc++.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
This commit fixes an incorrect reference to the configuration
`CT_GDB_NATIVE_STATIC_LIBSTDCXX` in the GDB build script.
Signed-off-by: Stephanos Ioannidis <root@stephanos.io>
... resulted in an attempt to build libinproctrace.so whenever any
of the {gdbserver, native gdb} was enabled.
Signed-off-by: Alexey Neyman <stilor@att.net>
... when it is compiled without the native GDB.
Also, fix the gdbserver to be installed without a program prefix in this
case, as it was before the unification of the GDB backend.
Signed-off-by: Alexey Neyman <stilor@att.net>
- Force building make as a companion tool if host make is older than
4.0 (CentOS 7 currently has 3.82)
- Disable 2.29 as a choice if host python is older than 3.4
(CentOS 7 has 2.6 unless python from EPEL is installed)
- Python2 emits its version information to STDERR. Ugh.
While there, also use the detected host Python for GDB configuration.
Signed-off-by: Alexey Neyman <stilor@att.net>
There is a subtle difference when executable bit is a part of the umask.
And at least some versions (Debian/stretch) fail if the resulting mode
would've been different if not for the umask setting.
Fixes#998.
Although, with such chmods/umasks it is likely that some package installation
will break anyway. But I'll leave it until somebody complains.
Signed-off-by: Alexey Neyman <stilor@att.net>
These changes mainly fix static linking errors when building static
native gdb and gdbserver (tested with gcc 7.2.0 + uClibc-ng 1.0.27 +
binutils 2.29.1 for MIPS):
[ALL ] .../lib/libstdc++.a(eh_throw.o): In function `__cxa_throw':
[ALL ] (.text.__cxa_throw+0x64): undefined reference to `_Unwind_RaiseException'
[ALL ] (.text.__cxa_throw+0x6c): undefined reference to `_Unwind_RaiseException'
[ALL ] .../lib/libstdc++.a(eh_throw.o): In function `__cxa_rethrow':
[ALL ] (.text.__cxa_rethrow+0x78): undefined reference to `_Unwind_Resume_or_Rethrow'
[ALL ] (.text.__cxa_rethrow+0x80): undefined reference to `_Unwind_Resume_or_Rethrow'
...
The problem is in mixing of CPP, CC, CXX, and LD with CPPFLAGS, CFLAGS,
CXXFLAGS, and LDFLAGS before passing to configure scripts.
gcc is sensitive to argument order and the scripts are normally responsible
to combine the variables in a proper way.
Signed-off-by: Sergey Korolev <s.korolev@ndmsystems.com>
... when using musl to compile strace.
Also, honor CT_TARGET_CFLAGS in scripts compiling target libs/binaries.
Signed-off-by: Alexey Neyman <stilor@att.net>
Some users (like myself) may want to omit the crosstool-NG version
from the binaries' versioning output, as it can be incredibly long
and not too helpful. Add a config option to disable it. The possible
combinations are as follows:
- crosstool-NG version (default)
- crosstool-NG version - custom toolchain ID
- Custom toolchain ID
- No crosstool-NG version OR custom toolchain ID
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
Check for python2/python3 and if found, pass them to --with-python.
Allow user to override the choice via a new config option. This
fixes systems where there is no "python", only "python2" or "python3".
Signed-off-by: Alexey Neyman <stilor@att.net>
It picks up gettext string and results in [ERROR] messages from ct-ng
when gettext strings happen inside an error() call.
Signed-off-by: Alexey Neyman <stilor@att.net>
... and then use the right option. See the note in scripts/functions
on where we should use ${foo} and where just 'foo'; this boils down to
whether we can expect the build tools override to be in effect (e.g. in
the actual build scripts) or not (i.e. outside of scripts/build).
While running in scripts/functions, or in scripts/crosstool-NG.sh the
build tools override directory (.build/tools/bin) may have not been
set up (yet, or at all).
Also, modify the installed scripts (populate, xldd) accordingly.
Signed-off-by: Alexey Neyman <stilor@att.net>
... when building native GDB/gdbserver.
Suggested by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
If GDB is turned off, the script will not be even sourced. Otherwise,
if GDB checkbox is set but none of the cross/native/gdbserver are
selected, debug.sh gives a bogus error message.
Signed-off-by: Alexey Neyman <stilor@att.net>
There are two separate issues with gdb configure usage:
1) inspecting build system libraries while cross-compiling;
2) preferring a shared library over static one.
The first usage issue is described and fixed now.
The second issue was described but the notes were removed
for some reason. This patch restores those notes.
Suggested-by: Alexey Neyman <stilor@att.net>
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
The referenced commit replaced 'make' with '${make}' everywhere. This is
wrong for at least the utilities that we may build as companion tools
(make, libtool): this will always invoke the version detected by configure
by supplying the absolute path. In other words, the wrappers in
.build/tools/bin are not fallbacks - they are either temporary (in case
a respective companion tool is built) or permanent redirectors.
This is the reason why the PATH= has .build/*/buildtools/bin at higher
precedence than .build/tools/bin; the latter has the versions detected by
configure and the former has the versions built as companion tools.
Revert the rest of the gang (grep/sed/...) for consistency. After all,
we may decide to supply some of them as well (awk, for instance).
Signed-off-by: Alexey Neyman <stilor@att.net>
This patch fixes libexpat detection for gdb-native and
gdb-cross static builds.
For gdb-native build configure should not touch system
/usr/{lib,include} directories while looking for libexpat.
To fix this we pass --without-libexpat-prefix flag
to configure script.
For gdb-cross build configure is allowed to investigate
system /usr/{lib,include} directories, but it does not
hurt to disable this behavior. In this case configure
falls back to -lexpat, which works as expected.
For more info:
http://marc.info/?l=gnulib-bug&m=129660262901148&w=2
Signed-off-by: Kirill Smirnov <kirill.k.smirnov@gmail.com>
Previous fix for cross-gdb broke powerpc-unknown_nofpu-linux-gnu which
uses an old GDB (6.8a). That GDB's configure chokes on $CC values with
multiple consecutive spaces; see the comment in 300-gdb.sh.
Signed-off-by: Alexey Neyman <stilor@att.net>
GDB's configure mishandles the libexpat.{so,a} libraries when it is
given -static in CFLAGS AND --with-libexpat-prefix in configure's args:
it checks for <prefix>/lib/libexpat.so and finding that, attempts to
link it as `gcc -static .. conftest.c <prefix>/lib/libexpat.so`; this
obviously fails (.so cannot be statically linked), so configure assumes
libexpat is unusable. Thus, --with-libexpat-prefix is dangerous and
should be avoided; instead, configure should find the libraries via the
supplied CC/LD definitions.
