Teach GDB how to dump memory tags for AArch64 when using the gcore command
and how to read memory tag data back from a core file generated by GDB
(via gcore) or by the Linux kernel.
The format is documented in the Linux Kernel documentation [1].
Each tagged memory range (listed in /proc/<pid>/smaps) gets dumped to its
own PT_AARCH64_MEMTAG_MTE segment. A section named ".memtag" is created for each
of those segments when reading the core file back.
To save a little bit of space, given MTE tags only take 4 bits, the memory tags
are stored packed as 2 tags per byte.
When reading the data back, the tags are unpacked.
I've added a new testcase to exercise the feature.
Build-tested with --enable-targets=all and regression tested on aarch64-linux
Ubuntu 20.04.
[1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)
The Linux kernel can dump memory tag segments to a core file, one segment
per mapped range. The format and documentation can be found in the Linux
kernel tree [1].
The following patch adjusts bfd and binutils so they can handle this new
segment type and display it accordingly. It also adds code required so GDB
can properly read/dump core file data containing memory tags.
Upon reading, each segment that contains memory tags gets mapped to a
section named "memtag". These sections will be used by GDB to lookup the tag
data. There can be multiple such sections with the same name, and they are not
numbered to simplify GDB's handling and lookup.
There is another patch for GDB that enables both reading
and dumping of memory tag segments.
Tested on aarch64-linux Ubuntu 20.04.
[1] Documentation/arm64/memory-tagging-extension.rst (Core Dump Support)
Newer distros carry newer headers that contains MTE definitions. Account
for that fact in the MTE testcases (gdb.arch/aarch64-mte.exp) and define
constants conditionally to prevent compilation failures.
Only check invalid relocation against protected symbol defined in shared
object.
bfd/
PR ld/29377
* elf32-i386.c (elf_i386_scan_relocs): Only check invalid
relocation against protected symbol defined in shared object.
* elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise.
ld/
PR ld/29377
* testsuite/ld-elf/linux-x86.exp: Run PR ld/29377 tests.
* testsuite/ld-elf/pr29377a.c: New file.
* testsuite/ld-elf/pr29377b.c: Likewise.
Currently, Python code can use event registries to detect when gdb
loads a new objfile, and when gdb clears the objfile list. However,
there's no way to detect the removal of an objfile, say when the
inferior calls dlclose.
This patch adds a gdb.free_objfile event registry and arranges for an
event to be emitted in this case.
I noticed that gdb.base/bt-on-fatal-signal.exp was contributing four
core files to the count of unexpected core files:
$ make check TESTS="gdb.base/bt-on-fatal-signal.exp"
=== gdb Summary ===
# of unexpected core files 4
# of expected passes 21
These are GDB core dumps. They are expected, however, because the
whole point of the testcase is to crash GDB with a signal.
Make GDB change its current directory to the output dir just before
crashing, so that the core files end up there. The result is now:
=== gdb Summary ===
# of expected passes 25
and:
$ find . -name "core.*"
./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1676506.nelson.1657727692
./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1672585.nelson.1657727671
./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1674833.nelson.1657727683
./testsuite/outputs/gdb.base/bt-on-fatal-signal/core.gdb.1673709.nelson.1657727676
(Note the test is skipped at the top if on a remote host.)
Change-Id: I79e4fb2e91330279c7a509930b1952194a72e85a
Currently the Ada code assumes that it can distinguish between a
multi-dimensional array and an array of arrays by looking for an
intervening typedef -- that is, for an array of arrays, there will be
a typedef wrapping the innermost array type.
A recent compiler change removes this typedef, which causes a gdb
failure in the internal AdaCore test suite.
This patch handles this case by checking whether the array type in
question has a name.
This patch removes ui_register_input_event_handler and
ui_unregister_input_event_handler, replacing them with methods on
'ui'. It also changes gdb to use these methods everywhere, rather
than sometimes reaching in to the ui to manage the file descriptor
directly.
Update the ARC disassembler to supply style information to the
disassembler output. The output formatting remains unchanged.
opcodes/ChangeLog:
* disassemble.c (disassemble_init_for_target): Set
created_styled_output for ARC based targets.
* arc-dis.c (find_format_from_table): Use fprintf_styled_ftype
instead of fprintf_ftype throughout.
(find_format): Likewise.
(print_flags): Likewise.
(print_insn_arc): Likewise.
Signed-off-by: Claudiu Zissulescu <claziss@gmail.com>
The ciphers 5,7, and 9 are missing when parsing an assembly
instruction leading to errors when those ciphers are
used.
gas/config
* tc-arc.c (md_assembly): Update strspn string with the
missing ciphers.
Signed-off-by: Claudiu Zissulescu <claziss@synopsys.com>
In commit 9d9dd861e98 ("[gdb/testsuite] Fix regression in
step-indirect-call-thunk.exp with gcc 7") I accidentally committed a duplicate
of supports_gnuc, which caused:
...
DUPLICATE: gdb.base/gdb-caching-proc.exp: supports_gnuc: consistency
...
Fix this by removing the duplicate.
Tested on x86_64-linux.
It is possible that a system might have a python3 executable, but no
python executable. For example, on my Fedora system the python2
package provides /usr/bin/python2, the python3 package provides
/usr/bin/python3, and the python-unversioned-command package provides
/usr/bin/python, which picks between python2 and python3.
It is quite possible to only have python3 available on a system.
Currently, when GDB configures, it looks for a 'python' executable.
If non is found then GDB will be built without python support. Or the
user needs to configure using --with-python=/usr/bin/python3.
This commit updates GDB's configure.ac script to first look for
'python', and then 'python3'. Now, on a system that only has a
python3 executable, GDB will automatically find, and use that in order
to provide python support, no user supplied configure arguments are
needed.
I've tested this on my local machine by removing the
python-unversioned-command package, confirming that there is no longer
a 'python' executable in my $PATH, and then rebuilding GDB from
scratch. GDB with this patch has python support.
Both forms were missing VexW0 (thus allowing Evex.W=1 to be encoded by
suitable means, which would cause #UD). The memory operand form further
was using the wrong Masking value, thus allowing zeroing-masking to be
encoded for the store form (which would again cause #UD).
This saves quite a number of shift instructions: The "operands" field
can now be retrieved by just masking (no shift), and extracting the
"extension_opcode" field now only requires a (signed) right shift, with
no prereq left one. (Of course there may be architectures where, in a
cross build, there might be no difference at all, e.g. when there are
suitable bitfield extraction insns.)
When running a task using parallel_for_each, we get the following
distribution:
...
Parallel for: n_elements: 7271
Parallel for: minimum elements per thread: 10
Parallel for: elts_per_thread: 1817
Parallel for: elements on worker thread 0 : 1817
Parallel for: elements on worker thread 1 : 1817
Parallel for: elements on worker thread 2 : 1817
Parallel for: elements on worker thread 3 : 0
Parallel for: elements on main thread : 1820
...
Note that there are 4 active threads, and scheduling elts_per_thread on each
of those handles 4 * 1817 == 7268, leaving 3 "left over" elements.
These leftovers are currently handled in the main thread.
That doesn't seem to matter much for this example, but for say 10 threads and
99 elements, you'd have 9 threads handling 9 elements and 1 thread handling 18
elements.
Instead, distribute the left over elements over the worker threads, such that
we have:
...
Parallel for: elements on worker thread 0 : 1818
Parallel for: elements on worker thread 1 : 1818
Parallel for: elements on worker thread 2 : 1818
Parallel for: elements on worker thread 3 : 0
Parallel for: elements on main thread : 1817
...
Tested on x86_64-linux.
Use set_sanitizer_default for ASAN_OPTIONS in lib/gdb.exp.
This allows us to override the default detect_leaks=0 setting, by manually
doing:
...
$ export ASAN_OPTIONS=detect_leaks=1
$ make check
...
Tested on x86_64-linux, by building with -fsanitize=address and running
test-case gdb.dwarf2/gdb-add-index.exp with and without
"export ASAN_OPTIONS=detect_leaks=1".
Since commit 43127ae5714 ("Fix gdb.base/step-indirect-call-thunk.exp") I run
into:
...
gdb compile failed, gcc: error: unrecognized command line option \
'-fcf-protection=none'; did you mean '-flto-partition=none'?
UNTESTED: gdb.base/step-indirect-call-thunk.exp: failed to prepare
...
The problem is that -fcf-protection is supported starting gcc 8, but I'm using
system gcc 7.5.0.
Fix this by only adding -fcf-protection=none for gcc 8 and later.
Tested on x86_64-linux, with gcc 7.5.0, 8.2.1 and 12.1.1.
Since commit c4a3dbaf113 ("Expose current 'print' settings to Python") we
have:
...
(gdb) print /x $bnd0 = {0x10, 0x20}^M
$22 = {lbound = 0x10, ubound = 0x20} : size 0x11^M
(gdb) FAIL: gdb.arch/i386-mpx.exp: verify size for bnd0
...
The regexp in the test-case expects "size 17".
Fix this by updating the regexp.
Tested on x86_64-linux.
Add a parallel_for_each_debug variable, set to false by default.
With an a.out compiled from hello world, we get with
parallel_for_each_debug == true:
...
$ gdb -q -batch a.out -ex start
...
Parallel for: n_elements: 7271
Parallel for: minimum elements per thread: 10
Parallel for: elts_per_thread: 1817
Parallel for: elements on worker thread 0 : 1817
Parallel for: elements on worker thread 1 : 1817
Parallel for: elements on worker thread 2 : 1817
Parallel for: elements on worker thread 3 : 0
Parallel for: elements on main thread : 1820
Temporary breakpoint 1, main () at /home/vries/hello.c:6
6 printf ("hello\n");
...
Tested on x86_64-linux.
gdb-add-index runs gdb with -iex 'set debuginfod enabled off'. If gdb
is not compiled against libdebuginfod this causes an unnecessary error
message to be printed to stderr indicating that gdb was not built with
debuginfod support.
Fix this by changing the 'set debuginfod enabled off' command to a
no-op when gdb isn't built with libdebuginfod.
gdb.base/maint.exp was using several gdb_expect statements, probably
because this test case predates the existance of gdb_test_multiple. This
commit updates the test case to use gdb_test_multiple, making it more
resilient to internal errors and such.
The only gdb_expect left in the testcase is one that specifically looks
for an internal error being triggered as a PASS.
When I rebased and updated the print_options patch, I forgot to update
print_options to add the new 'nibbles' feature to the result. This
patch fixes the oversight. I'm checking this in.
The test gdb.base/infcall-nested-structs-c.exp fails on a gdb assert
in function ppc64_sysv_abi_return_value in file gdb/ppc-sysv-tdep.c. The
assert is due to the missing IEEE 128-bit support in file
gdb/ppc-sysv-tdep.c.
The IBM long double was the initial float 128-bit support added by IBM
The IEEE 128-bit support, which is similar IBM long double support, was
made the default starting with GCC 12. The floating point format
differences include the number of bits used to encode the exponent
and significand. Also, IBM long double values are passed in a pair of
floating point registers. The IEEE 128-bit value is passed in a single
vector register.
This patch fixes the gdb_assert (ok); in function
ppc64_sysv_abi_return_value in gdb/ppc-sysv-tdep.c by adding IEEE FLOAT
128-bit type support for PowerPC.
The patch has been tested on Power 10, ELFv2. It fixes the following list
of regression failures on Power 10:
gdb.base/infcall-nested-structs-c.exp 192
gdb.base/infcall-nested-structs-c++.exp 76
gdb.base/structs.exp 9
The patch has been tested on Power 8 BE which is ELFv1.
This adds a 'summary' mode to Value.format_string and to
gdb.print_options. For the former, it lets Python code format values
using this mode. For the latter, it lets a printer potentially detect
if it is being called in a backtrace with 'set print frame-arguments'
set to 'scalars'.
I considered adding a new mode here to let a pretty-printer see
whether it was being called in a 'backtrace' context at all, but I'm
not sure if this is really desirable.
PR python/17291 asks for access to the current print options. While I
think this need is largely satisfied by the existence of
Value.format_string, it seemed to me that a bit more could be done.
First, while Value.format_string uses the user's settings, it does not
react to temporary settings such as "print/x". This patch changes
this.
Second, there is no good way to examine the current settings (in
particular the temporary ones in effect for just a single "print").
This patch adds this as well.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17291
Disable the Traceback Table generation on PowerPC for this test. The
Traceback Table consists of a series of bit fields to indicate things like
the Traceback Table version, language, and specific information about the
function. The Traceback Table is generated following the end of the code
for every function by default. The Traceback Table is defined in the
PowerPC ELF ABI and is intended to support debuggers and exception
handlers. The Traceback Table is displayed in the disassembly of functions
by default and is part of the function length. The table is typically
interpreted by the disassembler as data represented by .long xxx entries.
Generation of the Traceback Table is disabled in this test using the
PowerPC specific gcc compiler option -mtraceback=no, the xlc option
additional_flags-qtable=none and the clang optons
-mllvm -xcoff-traceback-table=false. Disabling the Traceback Table
generation in this test results in the gdb_test_multiple statement
correctly locating the address of the bclr instruction before the statement
"End of assembler dump." in the disassembly output.
When building gdb with -fsanitize-threads and running test-case
gdb.ada/char_enum_unicode.exp, I run into:
...
WARNING: ThreadSanitizer: data race (pid=21301)^M
Write of size 8 at 0x7b2000008080 by main thread:^M
#0 free <null> (libtsan.so.2+0x4c5e2)^M
#1 _dl_close_worker <null> (ld-linux-x86-64.so.2+0x4b7b)^M
#2 convert_between_encodings() charset.c:584^M
...
#21 cooked_index_functions::expand_symtabs_matching() read.c:18606
...
This is fixed by making cooked_index_functions::expand_symtabs_matching wait
for the cooked index finalization to be done.
Tested on x86_64-linux.
https://sourceware.org/bugzilla/show_bug.cgi?id=29311https://sourceware.org/bugzilla/show_bug.cgi?id=29286
Add a sequential_for_each alongside the parallel_for_each, which can be used
as a drop-in replacement.
This can be useful when debugging multi-threading behaviour, and you want to
limit multi-threading in a fine-grained way.
Tested on x86_64-linux, by using it instead of the parallel_for_each in
dwarf2_build_psymtabs_hard.
When building gdb with gcc 4.8.5, we run into:
...
In file included from /usr/include/c++/4.8/future:43:0,
from gdbsupport/thread-pool.h:30,
from gdb/dwarf2/cooked-index.h:33,
from gdb/dwarf2/read.h:26,
from gdb/dwarf2/abbrev-cache.c:21:
/usr/include/c++/4.8/atomic: In instantiation of \
‘_Tp std::atomic<_Tp>::load(std::memory_order) const [with _Tp = \
packed<dwarf_unit_type, 1ul>; std::memory_order = std::memory_order]’:
gdb/dwarf2/read.h:332:44: required from here
/usr/include/c++/4.8/atomic:208:13: error: no matching function for call to \
‘packed<dwarf_unit_type, 1ul>::packed()’
_Tp tmp;
^
...
Fix this by adding the default constructor for packed.
Tested on x86_64-linux, with gdb build with gcc 4.8.5.
When building gdb with -fsanitize=thread and running test-case
gdb.dwarf2/inlined_subroutine-inheritance.exp, we run into a data race
between:
...
Read of size 1 at 0x7b2000003010 by thread T4:
#0 packed<language, 1ul>::operator language() const packed.h:54
#1 dwarf2_per_cu_data::set_lang(language) read.h:363
...
and:
...
Previous write of size 1 at 0x7b2000003010 by main thread:
#0 dwarf2_per_cu_data::set_lang(language) read.h:365
...
Fix this by making per_cu->m_lang atomic.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29286
With gdb with -fsanitize=thread and test-case gdb.ada/array_bounds.exp, I run
into a data race between:
...
Read of size 1 at 0x7b2000025f0f by main thread:
#0 packed<dwarf_unit_type, 1ul>::operator dwarf_unit_type() const packed.h:54
#1 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:339
...
and:
...
Previous write of size 1 at 0x7b2000025f0f by thread T3:
#0 dwarf2_per_cu_data::set_unit_type(dwarf_unit_type) read.h:341
...
Fix this by making per_cu->unit_type atomic.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29286
When doing:
...
$ gdb ./outputs/gdb.ada/char_enum_unicode/foo -batch -ex "break foo.adb:26"
...
with a gdb build with -fsanitize=thread I run into a data race:
...
WARNING: ThreadSanitizer: data race (pid=30917)
Write of size 8 at 0x7b0400004070 by main thread:
#0 free <null> (libtsan.so.2+0x4c5e2)
#1 xfree<char> gdbsupport/gdb-xfree.h:37 (gdb+0x650f17)
#2 charset_vector::clear() gdb/charset.c:703 (gdb+0x651354)
#3 charset_vector::~charset_vector() gdb/charset.c:697 (gdb+0x6512d3)
#4 <null> <null> (libtsan.so.2+0x32643)
#5 captured_main_1 gdb/main.c:1310 (gdb+0xa3975a)
...
The problem is that we're freeing the charset_vector elements in the destructor,
which may still be used by a worker thread.
Fix this by not freeing the charset_vector elements in the destructor.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29311
I meant to make this change before committing, to let compilers know
the code on the false branch of md_parse_name is dead.
* config/tc-ppc.c (ppc_parse_name): Return void.
* config/tc-ppc.h (md_parse_name): Always true.
(ppc_parse_name): Update prototype.
Allows register names to appear in symbol assignments, so for example
tocp = %r2
mr %r3,tocp
now assembles.
* gas/config/tc-ppc.c (REG_NAME_CNT): Delete, replace uses with
ARRAY_SIZE.
(register_name): Rename to..
(md_operand): ..this. Only handle %reg.
(cr_names): Rename to..
(cr_cond): ..this. Just keep conditions.
(ppc_parse_name): Add mode param. Search both cr_cond and
pre_defined_registers. Handle absolute and register symbol
values here rather than in expr.c:operand().
(md_assemble): Don't special case register name matching in
operands, except to set cr_operand as appropriate.
* gas/config/tc-ppc.h (md_operand): Don't define.
(md_parse_name, ppc_parse_name): Update.
* read.c (pseudo_set): Copy over entire O_register value.
* testsuite/gas/ppc/regsyms.d.
* testsuite/gas/ppc/regsyms.s: New test.
* testsuite/gas/ppc/ppc.exp: Run it.
A WIP version of a patch
(https://sourceware.org/pipermail/gdb-patches/2022-June/190202.html)
resulted in a bug that went unnoticed by the testuite, like so:
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: enable scheduler-locking, for main thread
continue
Continuing.
[New Thread 1251861.1251861]
No unwaited-for children left.
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: continue stops when the main thread exits
info threads
Id Target Id Frame
3 Thread 1251861.1251863 "no-unwaited-for" __pthread_clockjoin_ex (threadid=140737351558976, thread_return=0x0, clockid=<optimized out>, abstime=<optimized out>, block=<optimized out>) at pthread_join_common.c:145
4 Thread 1251861.1251861 "no-unwaited-for" <unavailable> in ?? ()
The current thread <Thread ID 1> has terminated. See `help thread'.
(gdb) PASS: gdb.threads/no-unwaited-for-left.exp: only thread 3 left, main thread terminated
Somehow, above, GDB re-added the zombie leader back before printing
"No unwaited-for children left.". The "only thread 3 left, main
thread terminated" test should have caught this, but didn't. That is
because the test's regexp has a ".*" after the part that matches
thread 3. This commit tightens that regexp to catch such a bug. It
also tightens the "only main thread left, thread 2 terminated" test's
regexp in the same way.
Change-Id: I8744f327a0aa0e2669d1ddda88247e99b91cefff
