The gdb_assert proc under-quotes the expression that is passed in.
This leads to weird code in a couple of spots that tries to
compensate:
gdb_assert {{$all_regs eq $completed_regs}} ...
The fix is to add a bit of quoting when evaluating the expression.
On aarch64-linux, I run into:
...
gdb compile failed, cc1: error: '-fsplit-stack' is not supported by this \
compiler configuration
UNTESTED: gdb.base/morestack.exp: failed to prepare
...
Fix this by requiring -fsplit-stack, such that we have instead:
...
UNSUPPORTED: gdb.base/morestack.exp: require failed: \
expr [have_compile_flag -fsplit-stack]
...
Tested on x86_64-linux and aarch64-linux.
On aarch64-linux, I run into:
...
Running gdb.reverse/time-reverse.exp ...
gdb compile failed, gdb.reverse/time-reverse.c: In function 'main':
gdb.reverse/time-reverse.c:39:12: error: 'SYS_time' undeclared \
(first use in this function); did you mean 'SYS_times'?
syscall (SYS_time, &time_global);
^~~~~~~~
SYS_times
gdb.reverse/time-reverse.c:39:12: note: each undeclared identifier is \
reported only once for each function it appears in
UNTESTED: gdb.reverse/time-reverse.exp: failed to prepare
...
Fix this by adding a new proc have_syscall, and requiring syscall time, such
that we have instead:
...
UNSUPPORTED: gdb.reverse/time-reverse.exp: require failed: \
expr [have_syscall time]
...
Tested on x86_64-linux and aarch64-linux.
If the hipcc compiler cannot be found in dejagnu's tool_root_dir, look
for it in $::env(ROCM_PATH) (if set). If hipcc is still not found,
fallback to "hipcc" so the compiler will be searched in the PATH. This
removes the fallback to the hard-coded "/opt/rocm/bin" prefix.
This change is done so ROCM tools are searched in a uniform manner.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Update allow_hipcc_tests so all gdb.rocm tests are skipped if we do not
have a working hipcc compiler available.
To achieve this, adjust gdb_simple_compile to ensure that the hip
program is saved in a ".cpp" file before calling hipcc otherwise
compilation will fail.
One thing to note is that it is possible to have a hipcc installed with
a CUDA backend. Compiling with this back-end will successfully result
in an application, but GDB cannot debug it (at least for the offload
part). In the context of the gdb.rocm tests, we want to detect such
situation where gdb_simple_compile would give a false positive.
To achieve this, this patch checks that there is at least one AMDGPU
device available and that hipcc can compile for this or those targets.
Detecting the device is done using the rocm_agent_enumerator tool which
is installed with the all ROCm installations (it is used by hipcc to
detect identify targets if this is not specified on the comand line).
This patch also makes the allow_hipcc_tests proc a cached proc.
Co-Authored-By: Pedro Alves <pedro@palves.net>
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Update allow_hipcc_tests to check that GDB has the amd-dbgapi support
built-in. Without this support, all tests using hipcc and the rocm
stack will fail.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Rename skip_hipcc_tests to allow_hipcc_tests so it can be used as a
"require" predicate in tests.
Use require in gdb.rocm/simple.exp.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Add a `-nonl' option to `gdb_test' making it possible to match output
from commands such as `output' that do not produce a new line sequence
at the end, e.g.:
(gdb) output 0
0(gdb)
Many gdb.compile C++ tests fail for me on Fedora 36. I think these
are largely bugs in the plugin, though I didn't investigate too
deeply. Once one failure is seen, this often cascades and sometimes
there are many timeouts.
For example, this can happen:
(gdb) compile code var = a->get_var ()
warning: Could not find symbol "_ZZ9_gdb_exprP10__gdb_regsE1a" for compiled module "/tmp/gdbobj-0xdI6U/out2.o".
1 symbols were missing, cannot continue.
I think this is probably a plugin bug because, IIRC, in theory these
symbols should be exempt from a lookup via gdb.
This patch arranges to catch any catastrophic failure and then simply
exit the entire .exp file.
This patch adds the foundation for GDB to be able to debug programs
offloaded to AMD GPUs using the AMD ROCm platform [1]. The latest
public release of the ROCm release at the time of writing is 5.4, so
this is what this patch targets.
The ROCm platform allows host programs to schedule bits of code for
execution on GPUs or similar accelerators. The programs running on GPUs
are typically referred to as `kernels` (not related to operating system
kernels).
Programs offloaded with the AMD ROCm platform can be written in the HIP
language [2], OpenCL and OpenMP, but we're going to focus on HIP here.
The HIP language consists of a C++ Runtime API and kernel language.
Here's an example of a very simple HIP program:
#include "hip/hip_runtime.h"
#include <cassert>
__global__ void
do_an_addition (int a, int b, int *out)
{
*out = a + b;
}
int
main ()
{
int *result_ptr, result;
/* Allocate memory for the device to write the result to. */
hipError_t error = hipMalloc (&result_ptr, sizeof (int));
assert (error == hipSuccess);
/* Run `do_an_addition` on one workgroup containing one work item. */
do_an_addition<<<dim3(1), dim3(1), 0, 0>>> (1, 2, result_ptr);
/* Copy result from device to host. Note that this acts as a synchronization
point, waiting for the kernel dispatch to complete. */
error = hipMemcpyDtoH (&result, result_ptr, sizeof (int));
assert (error == hipSuccess);
printf ("result is %d\n", result);
assert (result == 3);
return 0;
}
This program can be compiled with:
$ hipcc simple.cpp -g -O0 -o simple
... where `hipcc` is the HIP compiler, shipped with ROCm releases. This
generates an ELF binary for the host architecture, containing another
ELF binary with the device code. The ELF for the device can be
inspected with:
$ roc-obj-ls simple
1 host-x86_64-unknown-linux file://simple#offset=8192&size=0
1 hipv4-amdgcn-amd-amdhsa--gfx906 file://simple#offset=8192&size=34216
$ roc-obj-extract 'file://simple#offset=8192&size=34216'
$ file simple-offset8192-size34216.co
simple-offset8192-size34216.co: ELF 64-bit LSB shared object, *unknown arch 0xe0* version 1, dynamically linked, with debug_info, not stripped
^
amcgcn architecture that my `file` doesn't know about ----´
Running the program gives the very unimpressive result:
$ ./simple
result is 3
While running, this host program has copied the device program into the
GPU's memory and spawned an execution thread on it. The goal of this
GDB port is to let the user debug host threads and these GPU threads
simultaneously. Here's a sample session using a GDB with this patch
applied:
$ ./gdb -q -nx --data-directory=data-directory ./simple
Reading symbols from ./simple...
(gdb) break do_an_addition
Function "do_an_addition" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (do_an_addition) pending.
(gdb) r
Starting program: /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7ffff5db7640 (LWP 1082911)]
[New Thread 0x7ffef53ff640 (LWP 1082913)]
[Thread 0x7ffef53ff640 (LWP 1082913) exited]
[New Thread 0x7ffdecb53640 (LWP 1083185)]
[New Thread 0x7ffff54bf640 (LWP 1083186)]
[Thread 0x7ffdecb53640 (LWP 1083185) exited]
[Switching to AMDGPU Wave 2:2:1:1 (0,0,0)/0]
Thread 6 hit Breakpoint 1, do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
24 *out = a + b;
(gdb) info inferiors
Num Description Connection Executable
* 1 process 1082907 1 (native) /home/smarchi/build/binutils-gdb-amdgpu/gdb/simple
(gdb) info threads
Id Target Id Frame
1 Thread 0x7ffff5dc9240 (LWP 1082907) "simple" 0x00007ffff5e9410b in ?? () from /opt/rocm-5.4.0/lib/libhsa-runtime64.so.1
2 Thread 0x7ffff5db7640 (LWP 1082911) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
5 Thread 0x7ffff54bf640 (LWP 1083186) "simple" __GI___ioctl (fd=3, request=3222817548) at ../sysdeps/unix/sysv/linux/ioctl.c:36
* 6 AMDGPU Wave 2:2:1:1 (0,0,0)/0 do_an_addition (
a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
(gdb) bt
Python Exception <class 'gdb.error'>: Unhandled dwarf expression opcode 0xe1
#0 do_an_addition (a=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
b=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>,
out=<error reading variable: DWARF-2 expression error: `DW_OP_regx' operations must be used either alone or in conjunction with DW_OP_piece or DW_OP_bit_piece.>) at simple.cpp:24
(gdb) continue
Continuing.
result is 3
warning: Temporarily disabling breakpoints for unloaded shared library "file:///home/smarchi/build/binutils-gdb-amdgpu/gdb/simple#offset=8192&size=67208"
[Thread 0x7ffff54bf640 (LWP 1083186) exited]
[Thread 0x7ffff5db7640 (LWP 1082911) exited]
[Inferior 1 (process 1082907) exited normally]
One thing to notice is the host and GPU threads appearing under
the same inferior. This is a design goal for us, as programmers tend to
think of the threads running on the GPU as part of the same program as
the host threads, so showing them in the same inferior in GDB seems
natural. Also, the host and GPU threads share a global memory space,
which fits the inferior model.
Another thing to notice is the error messages when trying to read
variables or printing a backtrace. This is expected for the moment,
since the AMD GPU compiler produces some DWARF that uses some
non-standard extensions:
https://llvm.org/docs/AMDGPUDwarfExtensionsForHeterogeneousDebugging.html
There were already some patches posted by Zoran Zaric earlier to make
GDB support these extensions:
https://inbox.sourceware.org/gdb-patches/20211105113849.118800-1-zoran.zaric@amd.com/
We think it's better to get the basic support for AMD GPU in first,
which will then give a better justification for GDB to support these
extensions.
GPU threads are named `AMDGPU Wave`: a wave is essentially a hardware
thread using the SIMT (single-instruction, multiple-threads) [3]
execution model.
GDB uses the amd-dbgapi library [4], included in the ROCm platform, for
a few things related to AMD GPU threads debugging. Different components
talk to the library, as show on the following diagram:
+---------------------------+ +-------------+ +------------------+
| GDB | amd-dbgapi target | <-> | AMD | | Linux kernel |
| +-------------------+ | Debugger | +--------+ |
| | amdgcn gdbarch | <-> | API | <=> | AMDGPU | |
| +-------------------+ | | | driver | |
| | solib-rocm | <-> | (dbgapi.so) | +--------+---------+
+---------------------------+ +-------------+
- The amd-dbgapi target is a target_ops implementation used to control
execution of GPU threads. While the debugging of host threads works
by using the ptrace / wait Linux kernel interface (as usual), control
of GPU threads is done through a special interface (dubbed `kfd`)
exposed by the `amdgpu` Linux kernel module. GDB doesn't interact
directly with `kfd`, but instead goes through the amd-dbgapi library
(AMD Debugger API on the diagram).
Since it provides execution control, the amd-dbgapi target should
normally be a process_stratum_target, not just a target_ops. More
on that later.
- The amdgcn gdbarch (describing the hardware architecture of the GPU
execution units) offloads some requests to the amd-dbgapi library,
so that knowledge about the various architectures doesn't need to be
duplicated and baked in GDB. This is for example for things like
the list of registers.
- The solib-rocm component is an solib provider that fetches the list of
code objects loaded on the device from the amd-dbgapi library, and
makes GDB read their symbols. This is very similar to other solib
providers that handle shared libraries, except that here the shared
libraries are the pieces of code loaded on the device.
Given that Linux host threads are managed by the linux-nat target, and
the GPU threads are managed by the amd-dbgapi target, having all threads
appear in the same inferior requires the two targets to be in that
inferior's target stack. However, there can only be one
process_stratum_target in a given target stack, since there can be only
one target per slot. To achieve it, we therefore resort the hack^W
solution of placing the amd-dbgapi target in the arch_stratum slot of
the target stack, on top of the linux-nat target. Doing so allows the
amd-dbgapi target to intercept target calls and handle them if they
concern GPU threads, and offload to beneath otherwise. See
amd_dbgapi_target::fetch_registers for a simple example:
void
amd_dbgapi_target::fetch_registers (struct regcache *regcache, int regno)
{
if (!ptid_is_gpu (regcache->ptid ()))
{
beneath ()->fetch_registers (regcache, regno);
return;
}
// handle it
}
ptids of GPU threads are crafted with the following pattern:
(pid, 1, wave id)
Where pid is the inferior's pid and "wave id" is the wave handle handed
to us by the amd-dbgapi library (in practice, a monotonically
incrementing integer). The idea is that on Linux systems, the
combination (pid != 1, lwp == 1) is not possible. lwp == 1 would always
belong to the init process, which would also have pid == 1 (and it's
improbable for the init process to offload work to the GPU and much less
for the user to debug it). We can therefore differentiate GPU and
non-GPU ptids this way. See ptid_is_gpu for more details.
Note that we believe that this scheme could break down in the context of
containers, where the initial process executed in a container has pid 1
(in its own pid namespace). For instance, if you were to execute a ROCm
program in a container, then spawn a GDB in that container and attach to
the process, it will likely not work. This is a known limitation. A
workaround for this is to have a dummy process (like a shell) fork and
execute the program of interest.
The amd-dbgapi target watches native inferiors, and "attaches" to them
using amd_dbgapi_process_attach, which gives it a notifier fd that is
registered in the event loop (see enable_amd_dbgapi). Note that this
isn't the same "attach" as in PTRACE_ATTACH, but being ptrace-attached
is a precondition for amd_dbgapi_process_attach to work. When the
debugged process enables the ROCm runtime, the amd-dbgapi target gets
notified through that fd, and pushes itself on the target stack of the
inferior. The amd-dbgapi target is then able to intercept target_ops
calls. If the debugged process disables the ROCm runtime, the
amd-dbgapi target unpushes itself from the target stack.
This way, the amd-dbgapi target's footprint stays minimal when debugging
a process that doesn't use the AMD ROCm platform, it does not intercept
target calls.
The amd-dbgapi library is found using pkg-config. Since enabling
support for the amdgpu architecture (amdgpu-tdep.c) depends on the
amd-dbgapi library being present, we have the following logic for
the interaction with --target and --enable-targets:
- if the user explicitly asks for amdgcn support with
--target=amdgcn-*-* or --enable-targets=amdgcn-*-*, we probe for
the amd-dbgapi and fail if not found
- if the user uses --enable-targets=all, we probe for amd-dbgapi,
enable amdgcn support if found, disable amdgcn support if not found
- if the user uses --enable-targets=all and --with-amd-dbgapi=yes,
we probe for amd-dbgapi, enable amdgcn if found and fail if not found
- if the user uses --enable-targets=all and --with-amd-dbgapi=no,
we do not probe for amd-dbgapi, disable amdgcn support
- otherwise, amd-dbgapi is not probed for and support for amdgcn is not
enabled
Finally, a simple test is included. It only tests hitting a breakpoint
in device code and resuming execution, pretty much like the example
shown above.
[1] https://docs.amd.com/category/ROCm_v5.4
[2] https://docs.amd.com/bundle/HIP-Programming-Guide-v5.4
[3] https://en.wikipedia.org/wiki/Single_instruction,_multiple_threads
[4] https://docs.amd.com/bundle/ROCDebugger-API-Guide-v5.4
Change-Id: I591edca98b8927b1e49e4b0abe4e304765fed9ee
Co-Authored-By: Zoran Zaric <zoran.zaric@amd.com>
Co-Authored-By: Laurent Morichetti <laurent.morichetti@amd.com>
Co-Authored-By: Tony Tye <Tony.Tye@amd.com>
Co-Authored-By: Lancelot SIX <lancelot.six@amd.com>
Co-Authored-By: Pedro Alves <pedro@palves.net>
Currently, when GDB loads debug information from a separate debug
file, there are a couple of warnings that could be produced if things
go wrong.
In find_separate_debug_file_by_buildid (build-id.c) GDB can give a
warning if the separate debug file doesn't include any actual debug
information, and in separate_debug_file_exists (symfile.c) we can warn
if the CRC checksum in the separate debug file doesn't match the
checksum in the original executable.
The problem here is that, when looking up debug information, GDB will
try several different approaches, lookup by build-id, lookup by
debug-link, and then a lookup from debuginfod. GDB can potentially
give a warning from an earlier attempt, and then succeed with a later
attempt. In the cases I have run into this is primarily a warning
about some out of date debug information on my machine, but then GDB
finds the correct information using debuginfod. This can be confusing
to a user, they will see warnings from GDB when really everything is
working just fine.
For example:
warning: the debug information found in "/usr/lib/debug//lib64/ld-2.32.so.debug" \
does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).
This diagnostic was printed on Fedora 33 even when the correct
debuginfo was downloaded.
In this patch I propose that we defer any warnings related to looking
up debug information from a separate debug file. If any of the
approaches are successful then GDB will not print any of the warnings.
As far as the user is concerned, everything "just worked". Only if
GDB completely fails to find any suitable debug information will the
warnings be printed.
The crc_mismatch test compiles two executables: crc_mismatch and
crc_mismatch-2 and then strips them of debuginfo creating separate
debug files. The test then replaces crc_mismatch-2.debug with
crc_mismatch.debug to trigger "CRC mismatch" warning. A local
debuginfod server is setup to supply the correct debug file, now when
GDB looks up the debug info no warning is given.
The build-id-no-debug-warning.exp is similar to the previous test. It
triggers the "separate debug info file has no debug info" warning by
replacing the build-id based .debug file with the stripped binary and
then loading it to GDB. It then also sets up local debuginfod server
with the correct debug file to download to make sure no warnings are
emitted.
Following 7d82b08e9e ("gdb/dwarf: dump cooked index contents in
cooked_index_functions::dump"), I see some failures like:
(gdb) mt print objfiles with-mf^M
^M
Object file /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/with-mf/with-mf: Objfile at 0x614000005040, bfd at 0x6120000e08c0, 18 minsyms ^M
^M
Cooked index in use:^M
^M
...
(gdb) FAIL: gdb.base/with-mf.exp: check if index present
This is because the format of the "Cooked index in use" line changed
slightly. Adjust ensure_gdb_index to expect the trailing colon.
Change-Id: If0a87575c02d8a0bc0d4b8ead540c234c62760f8
In a following commit I managed to trigger the line feed scrolling
case in tuiterm.exp. This case is currently unhandled, and this
commit fills in this missing functionality.
The implementation is pretty simple, just scroll all the content up
one line at a time until the cursor is back on the screen (a single
line of scroll is all that should be needed).
This change is untested in this commit, but is required by the next
commit.
clean_restart accepts a single optional argument. Rather than using
{args} and handling the argument by hand, change it to use Tcl's own
argument-checking.
In the following patch, I change gdb.dap/basic-dap.exp such that after
waiting for some event, it checks if it received another event
meanwhile. To help with this, make dap_wait_for_event_and_check and
_dap_dap_wait_for_event return a list with everything received before
the event of interest. This is similar to what
dap_check_request_and_response returns.
Change-Id: I85c8980203a2dec833937e7552c2196bc137935d
I think that name describes a bit better what the proc does, it is
similar to "wait_for" in tuiterm.exp.
Change-Id: Ie55aa011e6595dd1b5a874db13881ba572ace419
The DAP helper functions generally return TON objects. However, callers
almost all immediately use ton::2dict to convert them to dicts, to
access their contents. This commits makes things a bit simpler for them
by having function return dicts directly instead.
The downside is that the TON objects contain type information. For
instance, a "2" in a TCL dict could have been the integer 2 or the
string "2" in JSON. By converting to TCL dicts, we lose that
information. If some tests specifically want to check the types of some
fields, I think we can add intermediary functions that return TON
objects, without having to complicate other callers who don't care.
Change-Id: I2ca47bea355bf459090bae8680c6a917350b5c3f
This catch didn't cause me any trouble, but for the same reason as the
preceding patch, I think it's a bit better to just let any exception
propagate, to make for easier debugging.
Change-Id: I1779e62c788b77fef2d50434edf4c3d2ec5e1c4c
Following some of my changes, dap_request_and_response was failing and I
didn't know why. I think it's better to make it not catch any
exception, and just make it do a simple "send request, read response".
If an exception is thrown while sending a request or reading a response,
things are going really badly, it's not like we'll want to recover from
that and continue the test.
Change-Id: I27568d3547f753c3a74e3e5a730d38a8caef9356
This helps following what happens when reading gdb.log. The downside is
that it becomes harder to tell what text is from GDB and what text is
going to GDB, but I think that seeing responses without seeing requests
is even more confusing. At least, the lines are prefix with >>>, so
when you see this, you know that until the end of the line, it's
something that was sent to GDB, and not GDB output.
Change-Id: I1ba1acd8b16f4e64686c5ad268cc41082951c874
Prefix some procs that are only used internally with an underscore, to
make it clear they are internal. If they need to be used by some test
later, we can always un-prefix them.
Change-Id: Iacb8e77363b5d1f8b98d9ba5a6d115aee5c8925d
A few tests work on two different targets that can't be detected with
a single call to istarget -- that proc only accepts globs, not regular
expressions.
This patch introduces a new is_any_target proc and then converts these
tests to use it in a 'require'.
PR record/29927 - reverse-finish requires two reverse next instructions to
reach previous source line
Currently on X86, when executing the finish command in reverse, gdb does a
single step from the first instruction in the callee to get back to the
caller. GDB stops on the last instruction in the source code line where
the call was made. When stopped at the last instruction of the source code
line, a reverse next or step command will stop at the first instruction
of the same source code line thus requiring two step/next commands to
reach the previous source code line. It should only require one step/next
command to reach the previous source code line.
By contrast, a reverse next or step command from the first line in a
function stops at the first instruction in the source code line where the
call was made.
This patch fixes the reverse finish command so it will stop at the first
instruction of the source line where the function call was made. The
behavior on X86 for the reverse-finish command now matches doing a
reverse-next from the beginning of the function.
The proceed_to_finish flag in struct thread_control_state is no longer
used. This patch removes the declaration, initialization and setting of
the flag.
This patch requires a number of regression tests to be updated. Test
gdb.mi/mi-reverse.exp no longer needs to execute two steps to get to the
previous line. The gdb output for tests gdb.reverse/until-precsave.exp
and gdb.reverse/until-reverse.exp changed slightly. The expected result in
tests gdb.reverse/amd64-failcall-reverse.exp and
gdb.reverse/singlejmp-reverse.exp are updated to the correct expected
result.
This patch adds a new test gdb.reverse/finish-reverse-next.exp to test the
reverse-finish command when returning from the entry point and from the
body of the function.
The step_until proceedure in test gdb.reverse/step-indirect-call-thunk.exp
was moved to lib/gdb.exp and renamed cmd_until.
The patch has been tested on X86 and PowerPC to verify no additional
regression failures occured.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29927
The test suite uses the --configuration flag to feature-test gdb.
However, when I added this, I neglected to pass the internal gdbflags
to this, causing an error, which then caused failures in the test
suite (which would not be seen if you'd ever run "make install").
This patch fixes the bug. Tested by removing my install tree first,
to verify that I could reproduce the failure.
This changes skip_tui_tests to invert the sense, and renames it to
allow_tui_tests. It also rewrites this function to use the output of
"gdb --configuration", and it adds a note about the state of the TUI
to that output.
This changes skip_guile_tests to invert the sense, and renames it to
allow_guile_tests. It also rewrites this proc to check the output of
"gdb --configuration", as was done for Python. Then it changes the
code to use "require" where possible.
This changes skip_hw_breakpoint_tests to invert the sense, and renames
it to allow_hw_breakpoint_tests. This also converts some tests to use
"require" -- I missed this particular check in the first series.
