Tankut's recent patches made me realize that thread_pool::post_task
should have used an rvalue reference for its parameter. This patch
makes this change.
gdbsupport/ChangeLog
2021-04-30 Tom Tromey <tromey@adacore.com>
* thread-pool.cc (thread_pool::post_task): Update.
* thread-pool.h (class thread_pool) <post_task>: Take rvalue
reference to function.
Previously, the observers attached to an observable were always notified
in the order in which they had been attached. That order is not easily
controlled, because observers are typically attached in _initialize_*
functions, which are called in an undefined order.
However, an observer may require that another observer attached only
later is called before itself is.
Therefore, extend the 'observable' class to allow explicitly specifying
dependencies when attaching observers, by adding the possibility to
specify tokens for observers that it depends on.
To make sure dependencies are notified before observers depending on
them, the vector holding the observers is sorted in a way that
dependencies come before observers depending on them. The current
implementation for sorting uses the depth-first search algorithm for
topological sorting as described at [1].
Extend the observable unit tests to cover this case as well. Check that
this works for a few different orders in which the observers are
attached.
This newly introduced mechanism to explicitly specify dependencies will
be used in a follow-up commit.
[1] https://en.wikipedia.org/wiki/Topological_sorting#Depth-first_search
Tested on x86_64-linux (Debian testing).
gdb/ChangeLog:
* unittests/observable-selftests.c (dependency_test_counters):
New.
(observer_token0, observer_token1, observer_token2,
observer_token3, observer_token4, observer_token5): New.
(struct dependency_observer_data): New struct.
(observer_dependency_test_callback): New function.
(test_observers): New.
(run_dependency_test): New function.
(test_dependency): New.
(_initialize_observer_selftest): Register dependency test.
gdbsupport/ChangeLog:
* observable.h (class observable): Extend to allow specifying
dependencies between observers, keep vector holding observers
sorted so that dependencies are notified before observers
depending on them.
Change-Id: I5399def1eeb69ca99e28c9f1fdf321d78b530bdb
Switch observer to use the "new" debug printf mechanism and sprinkle a
few debug prints. Here's a small example of the output with "infrun"
and "observer" debug output enabled:
[infrun] proceed: enter
[observer] notify: start: observable target_resumed notify() called
[observer] notify: start: calling observer mi-interp of observable target_resumed
[observer] notify: end: calling observer mi-interp of observable target_resumed
[observer] notify: start: calling observer py-inferior of observable target_resumed
[observer] notify: end: calling observer py-inferior of observable target_resumed
[observer] notify: end: observable target_resumed notify() called
...
gdbsupport/ChangeLog:
* observable.h (observer_debug_printf,
OBSERVER_SCOPED_DEBUG_START_END): New.
(class observable) <notify, attach>: Use them.
Change-Id: If3ae4b6b65450ca3b7cae56698a87fc526688b86
A little thing that bothers me with scoped_debug_start_end is that it's
not possible to pass a format string to add context to the messages: the
start and end messages are fixed.
It was done like this at the time because there's the risk that debug
output is not enabled on entry (when the constructor runs) but is
enabled on exit (when the destructor runs). For example, a user
debugging from a top-gdb may manually enable a debug_foo variable. If
debug output is disabled while the constructor runs, we won't render the
format string (to minimize overhead) so it won't be available in the
destructor.
I think it would be nice to be able to use a format string along with
scoped_debug_start_end, and I think it's unfortunate that such a narrow
use case prevents it. So with this patch, I propose that we allow
passing a format string to scoped_debug_start_end, and if the rare
situation described above happens, then we just show a "sorry, message
not available" kind of message.
The following patch makes use of this.
gdbsupport/ChangeLog:
* common-debug.h (struct scoped_debug_start_end)
<scoped_debug_start_end>: Change start_msg/end_msg for
start_prefix/end_prefix. Add format string parameter and make
variadic.
<~scoped_debug_start_end>: Adjust.
<m_end_msg>: Rename to...
<m_end_prefix>: ... this.
<m_with_format>: New.
<m_msg>: New.
(scoped_debug_start_end): Make variadic.
(scoped_debug_enter_exit): Adjust.
Change-Id: I9427ce8877a246a46694b3a1fec3837dc6954d6e
Give a name to each observer, this will help produce more meaningful
debug message.
gdbsupport/ChangeLog:
* observable.h (class observable) <struct observer> <observer>:
Add name parameter.
<name>: New field.
<attach>: Add name parameter, update all callers.
Change-Id: Ie0cc4664925215b8d2b09e026011b7803549fba0
Instead of using a pair. This allows keeping more data per observer in
a structured way, and using field names is clearer than first/second.
gdbsupport/ChangeLog:
* observable.h (class observable) <struct observer>: New.
<detach, notify>: Update.
<m_observers>: Change type to vector of observers.
Change-Id: Iadf7d1fa25049cfb089e6b1b429ddebc548825ab
While doing some changes, some code failed to compile because it used
the scoped_debug_start_end macro, but couldn't find the CONCAT macro.
Fix that by making common-debug.h include preprocessor.h, the header
file that provides CONCAT.
gdbsupport/ChangeLog:
* common-debug.h: Include preprocessor.h.
Change-Id: Ibf863a932a18cba9a57b4bd72df538ef52d39127
Add new commands under the "memory-tag" prefix to allow users to inspect,
modify and check memory tags in different ways.
The available subcommands are the following:
- memory-tag print-logical-tag <expression>: Prints the logical tag for a
particular address.
- memory-tag withltag <expression> <tag>: Prints the address tagged with the
logical tag <tag>.
- memory-tag print-allocation-tag <expression>: Prints the allocation tag for
a particular address.
- memory-tag setatag <expression> <length> <tags>: Sets one or more allocation
tags to the specified tags.
- memory-tag check <expression>: Checks if the logical tag in <address>
matches its allocation tag.
These commands make use of the memory tagging gdbarch methods, and are still
available, but disabled, when memory tagging is not supported by the
architecture.
I've pondered about a way to make these commands invisible when memory tagging
is not available, but given the check is at runtime (and support may come and go
based on a process' configuration), that is a bit too late in the process to
either not include the commands or get rid of them.
Ideas are welcome.
gdb/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* printcmd.c: Include gdbsupport/rsp-low.h.
(memory_tag_list): New static global.
(process_print_command_args): Factored out of
print_command_1.
(print_command_1): Use process_print_command_args.
(show_addr_not_tagged, show_memory_tagging_unsupported)
(memory_tag_command, memory_tag_print_tag_command)
(memory_tag_print_logical_tag_command)
(memory_tag_print_allocation_tag_command, parse_with_logical_tag_input)
(memory_tag_with_logical_tag_command, parse_set_allocation_tag_input)
(memory_tag_set_allocation_tag_command, memory_tag_check_command): New
functions.
(_initialize_printcmd): Add "memory-tag" prefix and subcommands.
gdbsupport/ChangeLog:
2021-03-24 Luis Machado <luis.machado@linaro.org>
* rsp-low.cc (fromhex, hex2bin): Move to ...
* common-utils.cc: ... here.
(fromhex) Change error message text to not be RSP-specific.
* rsp-low.h (fromhex, hex2bin): Move to ...
* common-utils.h: ... here.
bfd/
* bfd-in.h (startswith): New inline.
(CONST_STRNEQ): Use startswith.
* bfd-in2.h: Regenerate.
gdbsupport/
* common-utils.h (startswith): Delete version now supplied by bfd.h.
libctf/
* ctf-impl.h: Include string.h.
This fixes PR27184, a failure to compile gdb due to
cdefs.h being out of sync with glibc on ppc64le targets
which are compiled with -mabi=ieeelongdouble and glibc
2.32.
Likewise, update usage of _GL_ATTRIBUTE_FORMAT_PRINTF to
_GL_ATTRIBUTE_FORMAT_PRINTF_STANDARD.
Likewise, disable newly added rpl_free gnulib api in
gdbserver support libraries.
Likewise, undefine read/write macros before redefining them
on mingw targets.
Likewise, wrap C++ usage of free with GNULIB_NAMESPACE namespace
as needed.
Change-Id: I86517613c0d8ac8f5ea45bbc4ebe2b54a3aef29f
Before this patch, gdb_tilde_expand would use glob(3) in order to expand
tilde at the begining of a path. This implementation has limitation when
expanding a tilde leading path to a non existing file since glob fails to
expand.
This patch proposes to use glob only to expand the tilde component of the
path and leaves the rest of the path unchanged.
This patch is a followup to the following discution:
https://sourceware.org/pipermail/gdb-patches/2021-January/174776.html
Before the patch:
gdb_tilde_expand("~") -> "/home/lsix"
gdb_tilde_expand("~/a/c/b") -> error() is called
After the patch:
gdb_tilde_expand("~") -> "/home/lsix"
gdb_tilde_expand("~/a/c/b") -> "/home/lsix/a/c/b"
Tested on x84_64 linux.
gdb/ChangeLog:
* Makefile.in (SELFTESTS_SRCS): Add
unittests/gdb_tilde_expand-selftests.c.
* unittests/gdb_tilde_expand-selftests.c: New file.
gdbsupport/ChangeLog:
* gdb_tilde_expand.cc (gdb_tilde_expand): Improve
implementation.
(gdb_tilde_expand_up): Delegate logic to gdb_tilde_expand.
* gdb_tilde_expand.h (gdb_tilde_expand): Update description.
This is the next in the new-style debug macro series.
For this one, I decided to omit the function name from the "Sending packet" /
"Packet received" kind of prints, just because it's not very useful in that
context and hinders readability more than anything else. This is completely
arbitrary.
This is with:
[remote] putpkt_binary: Sending packet: $qTStatus#49...
[remote] getpkt_or_notif_sane_1: Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::
and without:
[remote] Sending packet: $qTStatus#49...
[remote] Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::
A difference is that previously, the query packet and its reply would be
printed on the same line, like this:
Sending packet: $qTStatus#49...Packet received: T0;tnotrun:0;tframes:0;tcreated:0;tfree:500000;tsize:500000;circular:0;disconn:0;starttime:0;stoptime:0;username:;notes::
Now, they are printed on two lines, since each remote_debug_printf{,_nofunc}
prints its own complete message including an end of line. It's probably
a matter of taste, but I prefer the two-line version, it's easier to
follow, especially when the query packet is long.
As a result, lib/range-stepping-support.exp needs to be updated, as it
currently expects the vCont packet and the reply to be on the same line.
I think it's sufficient in that context to just expect the vCont packet
and not the reply, since the goal is just to count how many vCont;r GDB
sends.
gdb/ChangeLog:
* remote.h (remote_debug_printf): New.
(remote_debug_printf_nofunc): New.
(REMOTE_SCOPED_DEBUG_ENTER_EXIT): New.
* remote.c: Use above macros throughout file.
gdbsupport/ChangeLog:
* common-debug.h (debug_prefixed_printf_cond_nofunc): New.
* common-debug.c (debug_prefixed_vprintf): Handle a nullptr
func.
gdb/testsuite/ChangeLog:
* lib/range-stepping-support.exp (exec_cmd_expect_vCont_count):
Adjust to "set debug remote" changes.
Change-Id: Ica6dead50d3f82e855c7d763f707cef74bed9fee
As reported in PR 27157, if some environment variables read at startup
by GDB are defined but empty, we hit the assert in gdb_abspath:
$ XDG_CACHE_HOME= ./gdb -nx --data-directory=data-directory -q
AddressSanitizer:DEADLYSIGNAL
=================================================================
==2007040==ERROR: AddressSanitizer: SEGV on unknown address 0x0000000001b0 (pc 0x5639d4aa4127 bp 0x7ffdac232c00 sp 0x7ffdac232bf0 T0)
==2007040==The signal is caused by a READ memory access.
==2007040==Hint: address points to the zero page.
#0 0x5639d4aa4126 in target_stack::top() const /home/smarchi/src/binutils-gdb/gdb/target.h:1334
#1 0x5639d4aa41f1 in inferior::top_target() /home/smarchi/src/binutils-gdb/gdb/inferior.h:369
#2 0x5639d4a70b1f in current_top_target() /home/smarchi/src/binutils-gdb/gdb/target.c:120
#3 0x5639d4b00591 in gdb_readline_wrapper_cleanup::gdb_readline_wrapper_cleanup() /home/smarchi/src/binutils-gdb/gdb/top.c:1046
#4 0x5639d4afab31 in gdb_readline_wrapper(char const*) /home/smarchi/src/binutils-gdb/gdb/top.c:1104
#5 0x5639d4ccce2c in defaulted_query /home/smarchi/src/binutils-gdb/gdb/utils.c:893
#6 0x5639d4ccd6af in query(char const*, ...) /home/smarchi/src/binutils-gdb/gdb/utils.c:985
#7 0x5639d4ccaec1 in internal_vproblem /home/smarchi/src/binutils-gdb/gdb/utils.c:373
#8 0x5639d4ccb3d1 in internal_verror(char const*, int, char const*, __va_list_tag*) /home/smarchi/src/binutils-gdb/gdb/utils.c:439
#9 0x5639d5151a92 in internal_error(char const*, int, char const*, ...) /home/smarchi/src/binutils-gdb/gdbsupport/errors.cc:55
#10 0x5639d5162ab4 in gdb_abspath(char const*) /home/smarchi/src/binutils-gdb/gdbsupport/pathstuff.cc:132
#11 0x5639d5162fac in get_standard_cache_dir[abi:cxx11]() /home/smarchi/src/binutils-gdb/gdbsupport/pathstuff.cc:228
#12 0x5639d3e76a81 in _initialize_index_cache() /home/smarchi/src/binutils-gdb/gdb/dwarf2/index-cache.c:325
#13 0x5639d4dbbe92 in initialize_all_files() /home/smarchi/build/binutils-gdb/gdb/init.c:321
#14 0x5639d4b00259 in gdb_init(char*) /home/smarchi/src/binutils-gdb/gdb/top.c:2344
#15 0x5639d4440715 in captured_main_1 /home/smarchi/src/binutils-gdb/gdb/main.c:950
#16 0x5639d444252e in captured_main /home/smarchi/src/binutils-gdb/gdb/main.c:1229
#17 0x5639d44425cf in gdb_main(captured_main_args*) /home/smarchi/src/binutils-gdb/gdb/main.c:1254
#18 0x5639d3923371 in main /home/smarchi/src/binutils-gdb/gdb/gdb.c:32
#19 0x7fa002d3f0b2 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x270b2)
#20 0x5639d392314d in _start (/home/smarchi/build/binutils-gdb/gdb/gdb+0x4d414d)
gdb_abspath doesn't handle empty strings, so handle this case in the
callers. If a variable is defined but empty, I think it's reasonable in
this case to just ignore it, as if it was not defined.
Note that this sometimes also lead to a segfault, because the failed
assertion happens very early during startup, before things are fully
initialized.
gdbsupport/ChangeLog:
PR gdb/27157
* pathstuff.cc (get_standard_cache_dir, get_standard_config_dir,
find_gdb_home_config_file): Add empty string check.
gdb/testsuite/ChangeLog:
PR gdb/27157
* gdb.base/empty-host-env-vars.exp: New test.
Change-Id: I8654d8e97e74e1dff6d308c111ae4b1bbf07bef9
I spent a lot of time reading infrun debug logs recently, and I think
they could be made much more readable by being indented, to clearly see
what operation is done as part of what other operation. In the current
format, there are no visual cues to tell where things start and end,
it's just a big flat list. It's also difficult to understand what
caused a given operation (e.g. a call to resume_1) to be done.
To help with this, I propose to add the new scoped_debug_start_end
structure, along with a bunch of macros to make it convenient to use.
The idea of scoped_debug_start_end is simply to print a start and end
message at construction and destruction. It also increments/decrements
a depth counter in order to make debug statements printed during this
range use some indentation. Some care is taken to handle the fact that
debug can be turned on or off in the middle of such a range. For
example, a "set debug foo 1" command in a breakpoint command, or a
superior GDB manually changing the debug_foo variable.
Two macros are added in gdbsupport/common-debug.h, which are helpers to
define module-specific macros:
- scoped_debug_start_end: takes a message that is printed both at
construction / destruction, with "start: " and "end: " prefixes.
- scoped_debug_enter_exit: prints hard-coded "enter" and "exit"
messages, to denote the entry and exit of a function.
I added some examples in the infrun module to give an idea of how it can
be used and what the result looks like. The macros are in capital
letters (INFRUN_SCOPED_DEBUG_START_END and
INFRUN_SCOPED_DEBUG_ENTER_EXIT) to mimic the existing SCOPE_EXIT, but
that can be changed if you prefer something else.
Here's an excerpt of the debug
statements printed when doing "continue", where a displaced step is
started:
[infrun] proceed: enter
[infrun] proceed: addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT
[infrun] global_thread_step_over_chain_enqueue: enqueueing thread Thread 0x7ffff75a5640 (LWP 2289301) in global step over chain
[infrun] start_step_over: enter
[infrun] start_step_over: stealing global queue of threads to step, length = 1
[infrun] start_step_over: resuming [Thread 0x7ffff75a5640 (LWP 2289301)] for step-over
[infrun] resume_1: step=1, signal=GDB_SIGNAL_0, trap_expected=1, current thread [Thread 0x7ffff75a5640 (LWP 2289301)] at 0x5555555551bd
[displaced] displaced_step_prepare_throw: displaced-stepping Thread 0x7ffff75a5640 (LWP 2289301) now
[displaced] prepare: selected buffer at 0x5555555550c2
[displaced] prepare: saved 0x5555555550c2: 1e fa 31 ed 49 89 d1 5e 48 89 e2 48 83 e4 f0 50
[displaced] amd64_displaced_step_copy_insn: copy 0x5555555551bd->0x5555555550c2: c7 45 fc 00 00 00 00 eb 13 8b 05 d4 2e 00 00 83
[displaced] displaced_step_prepare_throw: prepared successfully thread=Thread 0x7ffff75a5640 (LWP 2289301), original_pc=0x5555555551bd, displaced_pc=0x5555555550c2
[displaced] resume_1: run 0x5555555550c2: c7 45 fc 00
[infrun] infrun_async: enable=1
[infrun] prepare_to_wait: prepare_to_wait
[infrun] start_step_over: [Thread 0x7ffff75a5640 (LWP 2289301)] was resumed.
[infrun] operator(): step-over queue now empty
[infrun] start_step_over: exit
[infrun] proceed: start: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: resuming Thread 0x7ffff7da7740 (LWP 2289296)
[infrun] resume_1: step=0, signal=GDB_SIGNAL_0, trap_expected=0, current thread [Thread 0x7ffff7da7740 (LWP 2289296)] at 0x7ffff7f7d9b7
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: resuming Thread 0x7ffff7da6640 (LWP 2289300)
[infrun] resume_1: thread Thread 0x7ffff7da6640 (LWP 2289300) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: [Thread 0x7ffff75a5640 (LWP 2289301)] resumed
[infrun] proceed: resuming Thread 0x7ffff6da4640 (LWP 2289302)
[infrun] resume_1: thread Thread 0x7ffff6da4640 (LWP 2289302) has pending wait status status->kind = stopped, signal = GDB_SIGNAL_TRAP (currently_stepping=0).
[infrun] prepare_to_wait: prepare_to_wait
[infrun] proceed: end: resuming threads, all-stop-on-top-of-non-stop
[infrun] proceed: exit
We can easily see where the call to `proceed` starts and end. We can
also see why there are a bunch of resume_1 calls, it's because we are
resuming threads, emulating all-stop on top of a non-stop target.
We also see that debug statements nest well with other modules that have
been migrated to use the "new" debug statement helpers (because they all
use debug_prefixed_vprintf in the end. I think this is desirable, for
example we could see the debug statements about reading the DWARF info
of a library nested under the debug statements about loading that
library.
Of course, modules that haven't been migrated to use the "new" helpers
will still print without indentations. This will be one good reason to
migrate them.
I think the runtime cost (when debug statements are disabled) of this is
reasonable, given the improvement in readability. There is the cost of
the conditionals (like standard debug statements), one more condition
(if (m_must_decrement_print_depth)) and the cost of constructing a stack
object, which means copying a fews pointers.
Adding the print in fetch_inferior_event breaks some tests that use "set
debug infrun", because it prints a debug statement after the prompt. I
adapted these tests to cope with it, by using the "-prompt" switch of
gdb_test_multiple to as if this debug statement is part of the expected
prompt. It's unfortunate that we have to do this, but I think the debug
print is useful, and I don't want a few tests to get in the way of
adding good debug output.
gdbsupport/ChangeLog:
* common-debug.h (debug_print_depth): New.
(struct scoped_debug_start_end): New.
(scoped_debug_start_end): New.
(scoped_debug_enter_exit): New.
* common-debug.cc (debug_prefixed_vprintf): Print indentation.
gdb/ChangeLog:
* debug.c (debug_print_depth): New.
* infrun.h (INFRUN_SCOPED_DEBUG_START_END): New.
(INFRUN_SCOPED_DEBUG_ENTER_EXIT): New.
* infrun.c (start_step_over): Use
INFRUN_SCOPED_DEBUG_ENTER_EXIT.
(proceed): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT and
INFRUN_SCOPED_DEBUG_START_END.
(fetch_inferior_event): Use INFRUN_SCOPED_DEBUG_ENTER_EXIT.
gdbserver/ChangeLog:
* debug.cc (debug_print_depth): New.
gdb/testsuite/ChangeLog:
* gdb.base/ui-redirect.exp: Expect infrun debug print after
prompt.
* gdb.threads/ia64-sigill.exp: Likewise.
* gdb.threads/watchthreads-reorder.exp: Likewise.
Change-Id: I7c3805e6487807aa63a1bae318876a0c69dce949
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.
Make use of the safe-ctype replacements for the standard ctype
character checking functions in gdbsupport/common-utils.cc. The
gdbsupport library is included into both gdb and gdbserver, and on the
gdbserver side there are two targets, gdbserver itself, and also
libinproctrace.so.
libiberty was already being included in the gdbserver link command,
but was missing from the libinproctrace.so link. As a result, after
changing gdbsupport/common-utils.cc to depend on libiberty,
libinproctrace.so would no longer link until I modified its link line.
gdbserver/ChangeLog:
* Makefile.in (IPA_LIB): Include libiberty library.
gdbsupport/ChangeLog:
* gdbsupport/common-utils.cc: Change 'ctype.h' include to
'safe-ctype.h'.
(extract_string_maybe_quoted): Use safe-ctype function versions.
(is_digit_in_base): Likewise.
(digit_to_int): Likewise.
(strtoulst): Likewise.
(skip_spaces): Likewise.
(skip_to_space): Likewise.
The same pattern happens often to define a "debug_printf" macro:
#define displaced_debug_printf(fmt, ...) \
do \
{ \
if (debug_displaced) \
debug_prefixed_printf ("displaced", __func__, fmt, ##__VA_ARGS__); \
} \
while (0)
Move this pattern behind a helper macro, debug_prefixed_printf_cond and
update the existing macros to use it.
gdb/ChangeLog:
* displaced-stepping.h (displaced_debug_printf): Use
debug_prefixed_printf_cond.
* dwarf2/read.c (dwarf_read_debug_printf): Likewise.
(dwarf_read_debug_printf_v): Likewise.
* infrun.h (infrun_debug_printf): Likewise.
* linux-nat.c (linux_nat_debug_printf): Likewise.
gdbsupport/ChangeLog:
* common-debug.h (debug_prefixed_printf_cond): New.
* event-loop.h (event_loop_debug_printf): Use
debug_prefixed_printf_cond.
Change-Id: I1ff48b98b8d1cc405d1c7e8da8ceadf4e3a17f99
Use the LOCALAPPDATA environment variable to determine the cache dir
when running on Windows with native command line, otherwise nasty
warning "Couldn't determine a path for index cached directory" appears.
Change-Id: I77903f9f0cb4743555866b8aea892cef55132589
Currently when printing an XML description GDB prints enum values like
this:
<enum id="levels_type" size="4">
<field name="low" start="0"/>
<field name="high" start="1"/>
</enum>
This is incorrect, and is most likely a copy and paste error with the
struct and flags printing code. The correct syntax is:
<enum id="levels_type" size="4">
<evalue name="low" value="0"/>
<evalue name="high" value="1"/>
</enum>
A test is included to cover this functionality.
gdb/testsuite/ChangeLog:
* gdb.xml/maint-xml-dump-03.xml: New file.
gdbsupport/ChangeLog:
* tdesc.cc (print_xml_feature::visit): Print enum fields using
'evalue' syntax.
According to gdb online docs[1], XML target description enum types
have both name and size attributes. Currently GDB does not print the
size attribute. This commit fixes this. This change will be visible
in the output of the command `maint print xml-tdesc`.
There are other bugs with the print of enum types in XML target
descriptions, the next commit will fix these and include a test that
covers this patch.
[1] https://sourceware.org/gdb/current/onlinedocs/gdb/Enum-Target-Types.html#Enum-Target-Types
gdbsupport/ChangeLog:
* tdesc.cc (print_xml_feature::visit): Print enum size attribute.
libstdc++ might change so that it always implements std::thread, but
then have thread startup simply fail. This is being discussed here:
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558736.html
This patch pre-emptively changes gdb to handle this scenario. It
seemed fine to me to ignore all system errors at thread startup, so
that is what this does.
gdbsupport/ChangeLog
2020-11-20 Tom Tromey <tromey@adacore.com>
* thread-pool.cc (thread_pool::set_thread_count): Ignore system
errors.
A recent commit caused pathstuff.cc to fail to compile on mingw, like:
../../binutils-gdb/gdbsupport/pathstuff.cc:324:1: error: no previous declaration for 'std::string find_gdb_home_config_file(const char*, _stati64*)' [-Werror=missing-declarations]
Some newly-added #includes were changing which "stat" was being seen
by the compiler. This patch moves the includes to the header, so that
the declaration and definition now agree.
2020-11-10 Tom Tromey <tromey@adacore.com>
PR build/26848:
* pathstuff.h: Move include block here...
* pathstuff.cc: ... from here.
This commit effectively changes the default location of the .gdbinit
file, while maintaining backward compatibility.
For non Apple hosts the .gdbinit file will now be looked for in the
following locations:
$XDG_CONFIG_HOME/gdb/gdbinit
$HOME/.config/gdb/gdbinit
$HOME/.gdbinit
On Apple hosts the search order is instead:
$HOME/Library/Preferences/gdb/gdbinit
$HOME/.gdbinit
I've performed an extensive rewrite of the documentation, moving all
information about initialization files and where to find them into a
new @node, text from other areas has been moved into this one
location, and other areas cross-reference to this new @node as much as
possible.
gdb/ChangeLog:
* NEWS: Mention changes to config file search path.
* main.c
gdb/doc/ChangeLog:
* gdb.texinfo (Mode Options): Descriptions of initialization files
has been moved to 'Initialization Files'.
(Startup): Likewise.
(Initialization Files): New node.
(gdb man): Update to mention alternative file paths.
(gdbinit man): Likewise.
This adds a new get_standard_config_dir, which returns the name of the
configuration directory. In XDG, this is ~/.config/gdb/. Future
patches will make use of this.
2020-07-05 Tom Tromey <tom@tromey.com>
* pathstuff.h (get_standard_config_dir): Declare.
* pathstuff.cc (get_standard_config_dir): New function.
The *_debug_print_1 functions are all very similar, the only difference
being the subsystem name. Remove them all and make the logging macros
use a new debug_prefixed_printf function directly.
gdb/ChangeLog:
* infrun.c (infrun_debug_printf_1): Remove.
(displaced_debug_printf_1): Remove.
(stop_all_threads): Use debug_prefixed_printf.
* infrun.h (infrun_debug_printf_1): Remove.
(infrun_debug_printf): Use debug_prefixed_printf.
(displaced_debug_printf_1): Remove.
(displaced_debug_printf): Use debug_prefixed_printf.
* linux-nat.c (linux_nat_debug_printf_1): Remove.
(linux_nat_debug_printf): Use debug_prefixed_printf.
gdbsupport/ChangeLog:
* common-debug.cc (debug_prefixed_printf): New.
* common-debug.h (debug_prefixed_printf): New declaration.
* event-loop.cc (event_loop_debug_printf_1): Remove.
* event-loop.h (event_loop_debug_printf_1): Remove.
(event_loop_debug_printf): Use debug_prefixed_printf.
(event_loop_ui_debug_printf): Use debug_prefixed_printf.
Change-Id: Ib323087c7257f0060121d302055c41eb64aa60c6
autoupdate does this change, it fixes this warning:
configure.ac:50: warning: The macro `AC_FUNC_VFORK' is obsolete.
configure.ac:50: You should run autoupdate.
../../lib/autoconf/functions.m4:1944: AC_FUNC_VFORK is expanded from...
common.m4:20: GDB_AC_COMMON is expanded from...
configure.ac:50: the top level
There are not changes in the generated configure files.
gdbsupport/ChangeLog:
* common.m4: Replace AC_FUNC_VFORK with AC_FUNC_FORK.
Change-Id: I9de9f718c57e6d51c9734161f36c36ce39170325
For some reason, autoupdate isn't able to grok ptrace.m4:
$ autoupdate ptrace.m4
/usr/bin/m4:/tmp/auYjuodw/input.m4:171: ERROR: end of file in string
autoupdate: /usr/bin/m4 failed with exit status: 1
Honestly, I'm unable to grok it either. This patch re-indents it in a
way that I think is easier to read. With this patch applied, autoupdate
becomes able to parse ptrace.m4, but I chose to keep this re-indent in a
patch of its own.
All the changes in generated configure files consist of insignificant
whitespace changes.
gdb/ChangeLog:
* configure: Re-generate.
gdbserver/ChangeLog:
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure: Re-generate.
* ptrace.m4: Re-indent.
Change-Id: Ie2afab09fecc8b6d0cccccb47ac9756f3843881e
`autoconf -Wall` notes that AM_PROG_CC_STDC is obsolete:
Fixes this autoconf warning:
configure.ac:40: warning: 'AM_PROG_CC_STDC': this macro is obsolete.
configure.ac:40: You should simply use the 'AC_PROG_CC' macro instead.
configure.ac:40: Also, your code should no longer depend upon 'am_cv_prog_cc_stdc',
configure.ac:40: but upon 'ac_cv_prog_cc_stdc'.
aclocal.m4:770: AM_PROG_CC_STDC is expanded from...
configure.ac:40: the top level
Since we build with a C++ compiler now, I don't think this is relevant.
If you look at the messages removed from gdbsupport/aclocal.m4, it says
that this functionality is now integrated in AC_PROG_CC, which we
already call. So it might not even make a difference.
We had a local version of AM_PROG_CC_STDC, in gdb/acinclude.m4 (only
used by gdb/configure.ac), remove it.
gdb/ChangeLog:
* acinclude.m4 (AM_PROG_CC_STDC): Remove.
* configure: Re-generate.
* configure.ac: Remove AM_PROG_CC_STDC.
gdbsupport/ChangeLog:
* aclocal.m4: Re-generate.
* configure: Re-generate.
* configure.ac: Remove AM_PROG_CC_STDC.
Change-Id: Ic824393598805d4f78cda9d119f8af46096e9c73
`autoreconf -Wall` notes that AC_CANONICAL_SYSTEM is obsolete:
configure.ac:36: warning: The macro `AC_CANONICAL_SYSTEM' is obsolete.
Replace it by AC_CANONICAL_BUILD, AC_CANONICAL_HOST and
AC_CANONICAL_TARGET in configure.ac files in gdb, gdbserver and
gdbsupport. All three macros may not be needed everywhere, but it is
hard to completely audit the configure files to see which are required,
so I think it's better (and that there's no downside) to just call all
three.
gdb/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
gdbserver/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
gdbsupport/ChangeLog:
* configure.ac: Use AC_CANONICAL_{BUILD,HOST,TARGET} instead of
AC_CANONICAL_SYSTEM.
* configure: Re-generate.
Change-Id: Ifd0e21f1e478634e768b5de1b8ee06a7f690d863
This eliminates the need to specify the return type when using
handle_eintr. We let the compiler deduce it for us.
Also, use lowercase for function parameter names. Uppercase should
only be used on template parameters.
gdb/ChangeLog:
* nat/linux-waitpid.c: Include "gdbsupport/eintr.h".
(my_waitpid): Use gdb::handle_eintr.
gdbserver/ChangeLog:
* netbsd-low.cc (netbsd_waitpid, netbsd_process_target::kill)
(netbsd_qxfer_libraries_svr4): Use gdb::handle_eintr without
explicit type.
gdbsupport/ChangeLog:
* eintr.h (handle_eintr): Replace Ret template parameter with
ErrorValType. Use it as type of the failure value. Deduce the
function's return type using decltype. Use lowercase for function
parameter names.
ptrace.m4, providing the GDB_AC_PTRACE autoconf macro, is used by gdb,
gdbserver and gdbsupport. I think it would make sense to move it to
gdbsupport.
gdb/ChangeLog:
* acinclude.m4: Update ptrace.m4 path.
* ptrace.m4: Moved to gdbsupport.
gdbserver/ChangeLog:
* acinclude.m4: Update ptrace.m4 path.
gdbsupport/ChangeLog:
* Makefile.in: Re-generate.
* acinclude.m4: Update ptrace.m4 path.
* ptrace.m4: Move here.
Change-Id: I849c149fd5dd8c3b2b0af38654fb353e3727871b
This moves the simple_search_memory function to a new file,
gdbsupport/search.cc. The API is slightly changed to make it more
general. This generality is useful for wiring it to gdbserver, and
also for unit testing.
gdb/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* target.h (simple_search_memory): Don't declare.
* target.c (simple_search_memory): Move to gdbsupport.
(default_search_memory): Update.
* remote.c (remote_target::search_memory): Update.
gdbsupport/ChangeLog
2020-10-07 Tom Tromey <tromey@adacore.com>
* Makefile.in: Rebuild.
* Makefile.am (libgdbsupport_a_SOURCES): Add search.cc.
* search.h: New file.
* search.cc: New file.
The following patch needs to output debug prints from gdbsupport code.
Move debug_prefixed_vprintf so that it is possible to use it from
gdbsupport.
gdb/ChangeLog:
* debug.c (debug_prefixed_vprintf): Move to gdbsupport.
* debug.h: Remove.
* infrun.c: Include gdbsupport/common-debug.h.
* linux-nat.c: Likewise.
gdbsupport/ChangeLog:
* common-debug.cc (debug_prefixed_vprintf): Move here.
* common-debug.h (debug_prefixed_vprintf): Move here.
Change-Id: I5170065fc10a7a49c0f1bba67c691decb2cf3bcb
Assign names to event loop file handlers. They will be used in debug
messages when file handlers are invoked.
In GDB, each UI used to get its own unique number, until commit
cbe256847e ("Remove ui::num"). Re-introduce this field, and use it to
make a unique name for the handler.
I'm not too sure what goes on in ser-base.c, all I know is that it's
what is used when debugging remotely. I've just named the main handler
"serial". It would be good to have unique names there too. For instance
when debugging with two different remote connections, we'd ideally want
the handlers to have unique names. I didn't do it in this patch though.
gdb/ChangeLog:
* async-event.c (initialize_async_signal_handlers): Pass name to
add_file_handler
* event-top.c (ui_register_input_event_handler): Likewise.
* linux-nat.c (linux_nat_target::async): Likewise.
* run-on-main-thread.c (_initialize_run_on_main_thread):
Likewise
* ser-base.c (reschedule): Likewise.
(ser_base_async): Likewise.
* tui/tui-io.c: Likewise.
* top.h (struct ui) <num>: New field.
* top.c (highest_ui_num): New variable.
(ui::ui): Initialize num.
gdbserver/ChangeLog:
* linux-low.cc (linux_process_target::async): Pass name to
add_file_handler.
* remote-utils.cc (handle_accept_event): Likewise.
(remote_open): Likewise.
gdbsupport/ChangeLog:
* event-loop.h (add_file_handler): Add "name" parameter.
* event-loop.cc (struct file_handler) <name>: New field.
(create_file_handler): Add "name" parameter, assign it to file
handler.
(add_file_handler): Add "name" parameter.
Change-Id: I9f1545f73888ebb6778eb653a618ca44d105f92c
Don't pass random sun_len for the BSD's,
zero the whole structure as recommended for portability.
Reported by Coverity.
gdbsupport/ChangeLog:
* agent.cc (gdb_connect_sync_socket): Preinitialize addr with zeros.
With GCC 6.4 and 6.5 (at least), unit tests that use
gdbsupport/valid-expr.h's CHECK_VALID fail to compile, with:
In file included from src/gdb/unittests/offset-type-selftests.c:24:0:
src/gdb/unittests/offset-type-selftests.c: In substitution of 'template<class Expected, template<class ...> class Op, class ... Args> using is_detected_exact = std::is_same<Expected, typename gdb::detection_detail::detector<gdb::nonesuch, void, Op, Args ...>::type> [with Expected = selftests::offset_type::off_A&; Op = selftests::offset_type::check_valid_expr75::archetype; Args = {selftests::offset_type::off_A, selftests::offset_type::off_B}]':
src/gdb/unittests/offset-type-selftests.c:75:1: required from here
src/gdb/../gdbsupport/valid-expr.h:65:20: error: type/value mismatch at argument 2 in template parameter list for 'template<class Expected, template<class ...> class Op, class ... Args> using is_detected_exact = std::is_same<Expected, typename gdb::detection_detail::detector<gdb::nonesuch, void, Op, Args ...>::type>'
archetype, TYPES>::value == VALID, \
^
The important part is the "error: type/value mismatch" error. Seems
like that GCC doesn't understand that archetype is an alias template,
and is being strict in requiring a template class.
The fix here is then to make archetype a template class, to pacify
GCC. The resulting code looks like this:
template <TYPENAMES, typename = decltype (EXPR)>
struct archetype
{
};
static_assert (gdb::is_detected_exact<archetype<TYPES, EXPR_TYPE>,
archetype, TYPES>::value == VALID, "");
is_detected_exact<Expected, Op, Args> checks whether Op<Args> is type
Expected:
- For Expected, we pass the explicit EXPR_TYPE, overriding the
default parameter type of archetype.
- For Args we don't pass the last template parameter, so archtype
defaults to the EXPR's decltype.
So in essence, we're really checking whether EXPR_TYPE is the same as
decltype(EXPR).
We need to do the decltype in a template context in order to trigger
SFINAE instead of failing to compile.
The hunk in unittests/enum-flags-selftests.c becomes necessary,
because unlike with the current alias template version, this new
version makes GCC trigger -Wenum-compare warnings as well:
src/gdb/unittests/enum-flags-selftests.c:328:33: error: comparison between 'enum selftests::enum_flags_tests::RE' and 'enum selftests::enum_flags_tests::RE2' [-Werror=enum-compare]
CHECK_VALID (true, bool, RE () != RE2 ())
^
src/gdb/../gdbsupport/valid-expr.h:61:45: note: in definition of macro 'CHECK_VALID_EXPR_INT'
template <TYPENAMES, typename = decltype (EXPR)> \
^
Build-tested with:
- GCC {4.8.5, 6.4, 6.5, 7.3.1, 9.3.0, 11.0.0-20200910}
- Clang 10.0.0
gdbsupport/ChangeLog:
* valid-expr.h (CHECK_VALID_EXPR_INT): Make archetype a template
class instead of an alias template and adjust static_assert.
gdb/ChangeLog:
* unittests/enum-flags-selftests.c: Check whether __GNUC__ is
defined before using '#pragma GCC diagnostic' instead of checking
__clang__.
Remove the typedef (unneeded with C++). Re-format the comments to
follow the more common style.
gdbsupport/ChangeLog:
* event-loop.c (struct file_handler): Remove typedef, re-format.
Change-Id: I3aea21fba1eb2584c507de3412da4e4c98283b2d
FreeBSD systems have provided these functions in libutil since 7.1
release. The most recent release without support is 6.4 released in
November of 2008.
This also requires libutil-freebsd on GNU/kFreeBSD systems. I assume
that those systems have supported kinfo_get_file and kinfo_get_vmmap
over a similar timeframe.
gdb/ChangeLog:
* configure.ac: Remove check for kinfo_getvmmap().
* configure, config.in: Regenerate.
* fbsd-nat.c (fbsd_read_mapping): Remove
(fbsd_nat_target::find_memory_regions): Remove the procfs version.
(fbsd_nat_target::info_proc): Assume kinfo_getfile() and
kinfo_get_vmmap() are always present.
gdbsupport/ChangeLog:
* common.m4 (GDB_AC_COMMON): Refactor checks for kinfo_getfile().
* configure, config.in: Regenerate.
This patch started by adding comprehensive unit tests for enum_flags.
For the testing part, it adds:
- tests of normal expected uses of the API.
- checks that _invalid_ uses of the API would fail to compile. I.e.,
it validates that enum_flags really is a strong type, and that
incorrect mixing of enum types would be caught at compile time. It
pulls that off making use of SFINEA and C++11's decltype/constexpr.
This revealed many holes in the enum_flags API. For example, the f1
assignment below currently incorrectly fails to compile:
enum_flags<flags> f1 = FLAG1;
enum_flags<flags> f2 = FLAG2 | f1;
The unit tests also revealed that this useful use case doesn't work:
enum flag { FLAG1 = 1, FLAG2 = 2 };
enum_flags<flag> src = FLAG1;
enum_flags<flag> f1 = condition ? src : FLAG2;
It fails to compile because enum_flags<flag> and flag are convertible
to each other.
Turns out that making enum_flags be implicitly convertible to the
backing raw enum type was not a good idea.
If we make it convertible to the underlying type instead, we fix that
ternary operator use case, and, we find cases throughout the codebase
that should be using the enum_flags but were using the raw backing
enum instead. So it's a good change overall.
Also, several operators were missing.
These holes and more are plugged by this patch, by reworking how the
enum_flags operators are implemented, and making use of C++11's
feature of being able to delete methods/functions.
There are cases in gdb/compile/ where we need to call a function in a
C plugin API that expects the raw enum. To address cases like that,
this adds a "raw()" method to enum_flags. This way we can keep using
the safer enum_flags to construct the value, and then be explicit when
we need to get at the raw enum.
This makes most of the enum_flags operators constexpr. Beyond
enabling more compiler optimizations and enabling the new unit tests,
this has other advantages, like making it possible to use operator|
with enum_flags values in switch cases, where only compile-time
constants are allowed:
enum_flags<flags> f = FLAG1 | FLAG2;
switch (f)
{
case FLAG1 | FLAG2:
break;
}
Currently that fails to compile.
It also switches to a different mechanism of enabling the global
operators. The current mechanism isn't namespace friendly, the new
one is.
It also switches to C++11-style SFINAE -- instead of wrapping the
return type in a SFINAE-friently structure, we use an unnamed template
parameter. I.e., this:
template <typename enum_type,
typename = is_enum_flags_enum_type_t<enum_type>>
enum_type
operator& (enum_type e1, enum_type e2)
instead of:
template <typename enum_type>
typename enum_flags_type<enum_type>::type
operator& (enum_type e1, enum_type e2)
Note that the static_assert inside operator~() was converted to a
couple overloads (signed vs unsigned), because static_assert is too
late for SFINAE-based tests, which is important for the CHECK_VALID
unit tests.
Tested with gcc {4.8, 7.1, 9.3} and clang {5.0.2, 10.0.0}.
gdb/ChangeLog:
* Makefile.in (SELFTESTS_SRCS): Add
unittests/enum-flags-selftests.c.
* btrace.c (ftrace_update_caller, ftrace_fixup_calle): Use
btrace_function_flags instead of enum btrace_function_flag.
* compile/compile-c-types.c (convert_qualified): Use
enum_flags::raw.
* compile/compile-cplus-symbols.c (convert_one_symbol)
(convert_symbol_bmsym):
* compile/compile-cplus-types.c (compile_cplus_convert_method)
(compile_cplus_convert_struct_or_union_methods)
(compile_cplus_instance::convert_qualified_base):
* go-exp.y (parse_string_or_char): Add cast to int.
* unittests/enum-flags-selftests.c: New file.
* record-btrace.c (btrace_thread_flag_to_str): Change parameter's
type to btrace_thread_flags from btrace_thread_flag.
(record_btrace_cancel_resume, record_btrace_step_thread): Change
local's type to btrace_thread_flags from btrace_thread_flag. Add
cast in DEBUG call.
gdbsupport/ChangeLog:
* enum-flags.h: Include "traits.h".
(DEF_ENUM_FLAGS_TYPE): Declare a function instead of defining a
structure.
(enum_underlying_type): Update comment.
(namespace enum_flags_detail): New. Move struct zero_type here.
(EnumIsUnsigned, EnumIsSigned): New.
(class enum_flags): Make most methods constexpr.
(operator&=, operator|=, operator^=): Take an enum_flags instead
of an enum_type. Make rvalue ref versions deleted.
(operator enum_type()): Delete.
(operator&, operator|, operator^, operator~): Delete, moved out of
class.
(raw()): New method.
(is_enum_flags_enum_type_t): Declare.
(ENUM_FLAGS_GEN_BINOP, ENUM_FLAGS_GEN_COMPOUND_ASSIGN)
(ENUM_FLAGS_GEN_COMP): New. Use them to reimplement global
operators.
(operator~): Now constexpr and reimplemented.
(operator<<, operator>>): New deleted functions.
* valid-expr.h (CHECK_VALID_EXPR_5, CHECK_VALID_EXPR_6): New.
An earlier attempt at doing this had failed (wouldn't work in GCCs
around 4.8, IIRC), but now that I try again, it works. I suspect that
my previous attempt did not use the pre C++14-safe void_t (in
traits.h).
I want to switch to this model because:
- It's the standard detection idiom that folks will learn starting
with C++17.
- In the enum_flags unit tests, I have a static_assert that triggers
a warning (resulting in build error), which GCC does not suppress
because the warning is not being triggered in the SFINAE context.
Switching to the detection idiom fixes that. Alternatively,
switching to the C++03-style expression-validity checking with a
varargs overload would allow addressing that, but I think that
would be going backwards idiomatically speaking.
- While this patch shows a net increase of lines of code, the magic
being added to traits.h can be removed in a few years when we start
requiring C++17.
gdbsupport/ChangeLog:
* traits.h (struct nonesuch, struct detector, detected_or)
(detected_or_t, is_detected, detected_t, detected_or)
(detected_or_t, is_detected_exact, is_detected_convertible): New.
* valid-expr.h (CHECK_VALID_EXPR_INT): Use gdb::is_detected_exact.
This adds support for the bfloat16 datatype, which can be seen as a short
version of FP32, skipping the least significant 16 bits of the mantissa.
Since the datatype is currently only supported by the AVX512 registers,
the printing of bfloat16 values is only supported for xmm, ymm and zmm
registers.
gdb/ChangeLog:
2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com>
Felix Willgerodt <Felix.Willgerodt@intel.com>
* gdbarch.sh: Added bfloat16 type.
* gdbarch.c: Regenerated.
* gdbarch.h: Regenerated.
* gdbtypes.c (floatformats_bfloat16): New struct.
(gdbtypes_post_init): Add builtin_bfloat16.
* gdbtypes.h (struct builtin_type) <builtin_bfloat16>: New member.
(floatformats_bfloat16): New struct.
* i386-tdep.c (i386_zmm_type): Add field "v32_bfloat16"
(i386_ymm_type): Add field "v16_bfloat16"
(i386_gdbarch_init): Add set_gdbarch_bfloat16_format.
* target-descriptions.c (make_gdb_type): Add case TDESC_TYPE_BFLOAT16.
* gdbsupport/tdesc.cc (tdesc_predefined_types): New member bfloat16.
* gdbsupport/tdesc.h (tdesc_type_kind): New member TDESC_TYPE_BFLOAT16.
* features/i386/64bit-avx512.xml: Add bfloat16 type.
* features/i386/64bit-avx512.c: Regenerated.
* features/i386/64bit-sse.xml: Add bfloat16 type.
* features/i386/64bit-sse.c: Regenerated.
gdb/testsuite/ChangeLog:
2020-09-11 Moritz Riesterer <moritz.riesterer@intel.com>
Felix Willgerodt <Felix.Willgerodt@intel.com>
* x86-avx512bf16.c: New file.
* x86-avx512bf16.exp: Likewise.
* lib/gdb.exp (skip_avx512bf16_tests): New function.
