Simon Marchi [Wed, 1 Oct 2025 22:10:41 +0000 (18:10 -0400)]
gdb/doc: trim trailing whitespaces
My editor "accidentally" removed all trailing whitespaces from
gdb.texinfo while doing a change. That was mostly just an annoyance
but to avoid it happening again, I suggest removing them for good.
I look at the difference in the output of "make html". The new output
has some trailing whitespaces removed, but none of them seems to cause a
semantic difference. Not sure about other formats like info or pdf
though.
Change-Id: I3f349b28c581af69703365fea07e7b93614c987c Approved-By: Eli Zaretskii <eliz@gnu.org>
Andrew Burgess [Wed, 10 Sep 2025 16:05:26 +0000 (17:05 +0100)]
gdb: add core file name to 'info inferiors' output
This commit builds on the previous commit. In the future I am
proposing to move the core file BFD from the program_space into the
core_target. In the last commit I updated 'maint info program-spaces'
to remove the core file name from the output.
In this commit I'm adding the core file name to the 'info inferiors'
output.
My proposal is to add the core file as auxiliary information beneath
an inferior's line in the 'info inferiors' output. We already do
this vfork parent/child information.
The alternative would be to add the core file as an additional column
in the 'info inferiors' output, indeed, I did initially propose this:
But the problem with this is that the 'info inferiors' output can
easily become very long, and the line wrapping gets very messy, making
the output much harder to parse. The feedback on this initial
approach wasn't super strong, so I'm trying the auxiliary information
approach to see if this is liked more.
The new output looks like this:
(gdb) info inferiors
Num Description Connection Executable
* 1 process 54313 1 (core) /tmp/executable
core file /tmp/core.54313
The only other option I can think of, if this approach is not liked,
would be to add an entirely new command, 'info core-files', with
output like:
Num Core File
* 1 /tmp/corefile.core
The 'Num' column here would just be the inferior number again. In
effect this new command is just splitting the 'info inferiors' into
two commands.
I extended gdb.base/corefile.exp to check the current output style,
and updated the gdb.multi/multi-target-info-inferiors.exp test to take
the new output into account.
Andrew Burgess [Wed, 10 Sep 2025 09:32:48 +0000 (10:32 +0100)]
gdb: remove core file name from 'maint info program-spaces'
I'm currently working towards a goal of moving the core file BFD out
of program_space and into core_target. I believe this is a good
change to make as the core_target already holds a lot of state that is
parsed from the core file BFD, so storing the parsed, structured,
information in a different location to the original core file BFD
doesn't make sense to me.
In preparation for this change, the 'maint info program-spaces'
command needs updating. Currently this command lists the name of the
core file BFD that is loaded into each program space.
Once the core file moves into core_target then the core file really
becomes a property of the inferior.
We could try to retain the existing output by looking up which
inferior is active in a given program space, and find the core file
that way, however, I don't like this plan because GDB does support
shared program spaces, in theory, a target could exist where every
inferior shares a single program space. Even on more common POSIX
targets, after a vfork the parent and child share a program space.
Now the vfork case clearly doesn't impact the core file case, and I
don't know if GDB _actually_ supports any shared program space targets
any more.... but still, I don't think we should try to retain the
existing behaviour.
So, this commit removes the core file name from the 'maint info
program-spaces' output. The next commit will add the core file name
back in a new home.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey [Wed, 1 Oct 2025 16:27:15 +0000 (10:27 -0600)]
Introduce gdbsupport/cxx-thread.h and use it
This introduces a new file, gdbsupport/cxx-thread.h, which provides
stubs for the C++ threading functionality on systems that don't
support it.
On fully-working ports, this header just supplies a number of aliases
in the gdb namespace. So, for instance, gdb::mutex is just an alias
for std::mutex.
For non-working ports, compatibility stubs are provided for the subset
of threading functionality that's used in gdb. These generally do
nothing and assume single-threaded operation.
The idea behind this is to reduce the number of checks of
CXX_STD_THREAD, making the code cleaner.
Not all spots using CXX_STD_THREAD could readily be converted.
In particular:
* Unit tests
* --config output
* Code manipulating threads themselves
* The extension interrupting handling code
These all seem fine to me.
Note there's also a check in py-dap.c. This one is perhaps slightly
subtle: DAP starts threads on the Python side, but it relies on gdb
itself being thread-savvy, for instance in gdb.post_event.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Tom Tromey [Wed, 1 Oct 2025 16:27:37 +0000 (10:27 -0600)]
Don't rely on deduction in run-on-main-thread.c
This changes one spot in run-on-main-thread.c to use an explicit
template argument, rather than relying on deduction. The deduction
would otherwise fail with the next patch.
Andrew Burgess [Wed, 17 Sep 2025 12:07:09 +0000 (13:07 +0100)]
gdb: int to bool conversion in find_memory_regions API
Perform int to bool conversion for find_memory_region_ftype function
type. This function type is used in the find_memory_regions API, both
target_find_memory_regions and target_find_memory_regions.
There should be no user visible changes after this commit.
[AUTOFDO][AARCH64] Add support for profilebootstrap
Add support for autoprofiledbootstrap in aarch64.
This is similar to what is done for i386. Added
gcc/config/aarch64/gcc-auto-profile for aarch64 profile
creation.
How to run:
configure --with-build-config=bootstrap-lto
make autoprofiledbootstrap
[PATCH] configure: Always add pre-installed header directories to search path
configure script was adding the target directory flags, including the
'-B' flags for the executable prefix and the '-isystem' flags for the
pre-installed header directories, to the target flags only for
non-Canadian builds under the premise that the host binaries under the
executable prefix will not be able to execute on the build system for
Canadian builds.
While that is true for the '-B' flags specifying the executable prefix,
the '-isystem' flags specifying the pre-installed header directories are
not affected by this and do not need special handling.
This patch updates the configure script to always add the 'include' and
'sys-include' pre-installed header directories to the target search
path, in order to ensure that the availability of the pre-installed
header directories in the search path is consistent across non-Canadian
and Canadian builds.
When '--with-headers' flag is specified, this effectively ensures that
the libc headers, that are copied from the specified header directory to
the sys-include directory, are used by libstdc++.
cobol: Restrict COBOL to supported Linux arches [PR119217]
The COBOL frontend is currently built on all x86_64 and aarch64 hosts
although the code contains some Linux/glibc specifics that break the build
e.g. on Solaris/amd64.
config, toplevel, Darwin: Pass -B instead of -L to C++ commands.
Darwin from 10.11 needs embedded rpaths to find the correct libraries at
runtime. Recent increases in hardening have made it such that the dynamic
loader will no longer fall back to using an installed libstdc++ when the
(new) linked one is not found. This means we fail configure tests (that
should pass) for runtimes that use C++.
We can resolve this by passing '-B' to the C++ command lines instead of '-L'
(-B implies -L on Darwin, but also causes a corresponding embedded rpath).
bootstrap/119513 - fix cobol bootstrap with --enable-generated-files-in-srcdir
This adds gcc/cobol/parse.o to compare_exclusions and makes sure to
ignore errors when copying generated files, like it's done when
copying gengtype-lex.cc.
toplevel, libcobol: Add dependency on libquadmath build [PR119244].
For the configuration of libgcobol to be correct for targets that need
to use libquadmath for 128b FP support, we must be able to find the
quadmath library (or not, for targets that have the support in libc).
In addition to making libstdc++ itself available, this, via enabling
'build-gcc/*/libstdc++-v3/scripts/testsuite_flags', in particular also makes
the standard C++ headers available to 'make check-gcc-c++'. With that, there
are a lot of FAIL/UNRESOLVED -> PASS progressions, where we previously ran
into, for example:
FAIL: g++.dg/coroutines/co-await-syntax-00-needs-expr.C (test for errors, line 6)
FAIL: g++.dg/coroutines/co-await-syntax-00-needs-expr.C (test for excess errors)
Excess errors:
[...]/gcc/testsuite/g++.dg/coroutines/coro.h:132:10: fatal error: cstdlib: No such file or directory
Similarly, there are a lot of FAIL/UNRESOLVED -> UNSUPPORTED "progressions" due
to 'sorry, unimplemented: exception handling not supported'.
The 'make check-target-libstdc++-v3' results don't look too bad, either.
With libstdc++ now available, libgrust gets enabled, which we in turn again
have to disable, for 'sorry, unimplemented: exception handling not supported'
reasons.
Sorry, seems I've screwed up the earlier libgcobol/configure.tgt change.
Looking in more detail, the way e.g. libsanitizer/configure.tgt works is
that it is sourced twice, once at toplevel and there it just sets
UNSUPPORTED=1 for fully unsupported triplets, and then inside of
libsanitizer/configure where it decides to include or not include the
various sublibraries depending on the *_SUPPORTED flags.
So, the following patch attempts to do the same for libgcobol as well.
The BIULD_LIBGCOBOL automake conditional was unused, this patch guards it
on LIBGCOBOL_SUPPORTED as well and guards with it
toolexeclib_LTLIBRARIES = libgcobol.la
Also, AM_CFLAGS has been changed to AM_CXXFLAGS as there are just C++
sources in the library.
configure, Darwin: Require explicit selection of COBOL.
By defult, Darwin does not have sufficient tools to build COBOL
so we do not want to include it in --enable-languages=all since
this will break regular testing of all supported languages.
However, we do want to be able to build it on demand (where the
build system has sufficiently new tools) and so do not want to
disable it permanently.
..., where "support" means that the build doesn't fail, but it doesn't mean
that all target libraries get built and we get pretty test results for the
additional languages.
Since catching-syscalls was added, there had been added files containing
syscalls in xml format. As for now riscv-canonicalize-syscall-gen.py uses
glibc for generating, it may be not so comfortable. I changed this
script for reusing newly generated riscv-linux.xml file. Also, I renamed
riscv64_canonicalize_syscall to riscv_linux_canonicalize_syscall as only 64
system is supported in linux. This will simplify the possible further
generalization of this script to other architectures.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
H.J. Lu [Tue, 30 Sep 2025 03:23:58 +0000 (11:23 +0800)]
binutils: Use AC_TRY_COMPILE to check target clang/gcc
Use AC_TRY_COMPILE to check for the working target clang and gcc when
configuring for cross tools.
PR binutils/33503
* configure: Regenerated.
config/
PR binutils/33503
* clang-plugin.m4 (CLANG_PLUGIN_FILE_FOR_TARGET): Use
AC_TRY_COMPILE to check the target clang and replace
clang_cv_is_clang with clang_target_cv_working.
* gcc-plugin.m4 (GCC_PLUGIN_OPTION_FOR_TARGET): Use
AC_TRY_COMPILE to check the target gcc.
Simon Marchi [Fri, 19 Sep 2025 20:27:05 +0000 (16:27 -0400)]
gdb/dwarf: use dynamic partitioning for DWARF CU indexing
The DWARF indexer splits the work statically based on the unit sizes,
attempting to give each worker thread about the same amount of bytes to
process. This works relatively well with standard compilation. But
when compiling with DWO files (-gsplit-dwarf), it's not as good. I see
this when loading a relatively big program (telegram-desktop, which
includes a lot of static dependencies) compiled with -gsplit-dwarf:
Time for "DWARF indexing worker": wall 0.000, user 0.000, sys 0.000, user+sys 0.000, -nan % CPU
Time for "DWARF indexing worker": wall 0.001, user 0.000, sys 0.000, user+sys 0.000, 0.0 % CPU
Time for "DWARF indexing worker": wall 0.001, user 0.001, sys 0.000, user+sys 0.001, 100.0 % CPU
Time for "DWARF indexing worker": wall 0.748, user 0.284, sys 0.297, user+sys 0.581, 77.7 % CPU
Time for "DWARF indexing worker": wall 0.818, user 0.408, sys 0.262, user+sys 0.670, 81.9 % CPU
Time for "DWARF indexing worker": wall 1.196, user 0.580, sys 0.402, user+sys 0.982, 82.1 % CPU
Time for "DWARF indexing worker": wall 1.250, user 0.511, sys 0.500, user+sys 1.011, 80.9 % CPU
Time for "DWARF indexing worker": wall 7.730, user 5.891, sys 1.729, user+sys 7.620, 98.6 % CPU
Note how the wall times vary from 0 to 7.7 seconds. This is
undesirable, because the time to do that indexing step takes as long as
the slowest worker thread takes.
The imbalance in this step also causes imbalance in the following
"finalize" step:
Time for "DWARF finalize worker": wall 0.007, user 0.004, sys 0.002, user+sys 0.006, 85.7 % CPU
Time for "DWARF finalize worker": wall 0.012, user 0.005, sys 0.005, user+sys 0.010, 83.3 % CPU
Time for "DWARF finalize worker": wall 0.015, user 0.010, sys 0.004, user+sys 0.014, 93.3 % CPU
Time for "DWARF finalize worker": wall 0.389, user 0.359, sys 0.029, user+sys 0.388, 99.7 % CPU
Time for "DWARF finalize worker": wall 0.680, user 0.644, sys 0.035, user+sys 0.679, 99.9 % CPU
Time for "DWARF finalize worker": wall 0.929, user 0.907, sys 0.020, user+sys 0.927, 99.8 % CPU
Time for "DWARF finalize worker": wall 1.093, user 1.055, sys 0.037, user+sys 1.092, 99.9 % CPU
Time for "DWARF finalize worker": wall 2.016, user 1.934, sys 0.082, user+sys 2.016, 100.0 % CPU
Time for "DWARF finalize worker": wall 25.882, user 25.471, sys 0.404, user+sys 25.875, 100.0 % CPU
With DWO files, the split of the workload by size doesn't work, because
it is done using the size of the skeleton units in the main file, which
is not representative of how much DWARF is contained in each DWO file.
I haven't tried it, but a similar problem could occur with cross-unit
imports, which can happen with dwz or LTO. You could have a small unit
that imports a lot from other units, in which case the size of the units
is not representative of the work to accomplish.
To try to improve this situation, change the DWARF indexer to use
dynamic partitioning, using gdb::parallel_for_each_async. With this,
each worker thread pops one unit at a time from a shared work queue to
process it, until the queue is empty. That should result in a more
balance workload split. I chose 1 as the minimum batch size here,
because I judged that indexing one CU was a big enough piece of work
compared to the synchronization overhead of the queue. That can always
be tweaked later if someone wants to do more tests.
As a result, the timings are much more balanced:
Time for "DWARF indexing worker": wall 2.325, user 1.033, sys 0.573, user+sys 1.606, 69.1 % CPU
Time for "DWARF indexing worker": wall 2.326, user 1.028, sys 0.568, user+sys 1.596, 68.6 % CPU
Time for "DWARF indexing worker": wall 2.326, user 1.068, sys 0.513, user+sys 1.581, 68.0 % CPU
Time for "DWARF indexing worker": wall 2.326, user 1.005, sys 0.579, user+sys 1.584, 68.1 % CPU
Time for "DWARF indexing worker": wall 2.326, user 1.070, sys 0.516, user+sys 1.586, 68.2 % CPU
Time for "DWARF indexing worker": wall 2.326, user 1.063, sys 0.584, user+sys 1.647, 70.8 % CPU
Time for "DWARF indexing worker": wall 2.326, user 1.049, sys 0.550, user+sys 1.599, 68.7 % CPU
Time for "DWARF indexing worker": wall 2.328, user 1.058, sys 0.541, user+sys 1.599, 68.7 % CPU
...
Time for "DWARF finalize worker": wall 2.833, user 2.791, sys 0.040, user+sys 2.831, 99.9 % CPU
Time for "DWARF finalize worker": wall 2.939, user 2.896, sys 0.043, user+sys 2.939, 100.0 % CPU
Time for "DWARF finalize worker": wall 3.016, user 2.969, sys 0.046, user+sys 3.015, 100.0 % CPU
Time for "DWARF finalize worker": wall 3.076, user 2.957, sys 0.118, user+sys 3.075, 100.0 % CPU
Time for "DWARF finalize worker": wall 3.159, user 3.054, sys 0.104, user+sys 3.158, 100.0 % CPU
Time for "DWARF finalize worker": wall 3.198, user 3.082, sys 0.114, user+sys 3.196, 99.9 % CPU
Time for "DWARF finalize worker": wall 3.197, user 3.076, sys 0.121, user+sys 3.197, 100.0 % CPU
Time for "DWARF finalize worker": wall 3.268, user 3.136, sys 0.131, user+sys 3.267, 100.0 % CPU
Time for "DWARF finalize worker": wall 1.907, user 1.810, sys 0.096, user+sys 1.906, 99.9 % CPU
In absolute terms, the total time for GDB to load the file and exit goes
down from about 42 seconds to 17 seconds.
Some implementation notes:
- The state previously kept in as local variables in
cooked_index_worker_debug_info::process_units becomes fields of the
new parallel worker object.
- The work previously done for each unit in
cooked_index_worker_debug_info::process_units becomes the operator()
of the new parallel worker object.
- The work previously done at the end of
cooked_index_worker_debug_info::process_units (including calling
bfd_thread_cleanup) becomes the destructor of the new parallel worker
object.
- The "done" callback of gdb::task_group becomes the "done" callback of
gdb::parallel_for_each_async.
- I placed the parallel_indexing_worker struct inside
cooked_index_worker_debug_info, so that it has access to
parallel_indexing_worker's private fields (e.g. m_results, to push
the results). It will also be possible to re-use it for skeletonless
type units in a later patch.
Change-Id: I5dc5cf8793abe9ebe2659e78da38ffc94289e5f2 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 19 Sep 2025 20:27:04 +0000 (16:27 -0400)]
gdbsupport: add async parallel_for_each version
I would like to use gdb::parallel_for_each to implement the parallelism
of the DWARF unit indexing. However, the existing implementation of
gdb::parallel_for_each is blocking, which doesn't work with the model
used by the DWARF indexer, which is asynchronous and callback-based.
Add an asynchronouys version of gdb::parallel_for_each that will be
suitable for this task.
This new version accepts a callback that is invoked when the parallel
for each is complete.
This function uses the same strategy as gdb::task_group to invoke the
"done" callback: worker threads have a shared_ptr reference to some
object. The last worker thread to drop its reference causes the object
to be deleted, which invokes the callback.
Unlike for the sync version of gdb::parallel_for_each, it's not possible
to keep any state in the calling thread's stack, because that disappears
immediately after starting the workers. So all the state is kept in
that same shared object.
There is a limitation that the sync version doesn't have, regarding the
arguments you can pass to the worker objects: it's not possibly to rely
on references. There are more details in a comment in the code.
It would be possible to implement the sync version of
gdb::parallel_for_each on top of the async version, but I decided not to
do it to avoid the unnecessary dynamic allocation of the shared object,
and to avoid adding the limitations on passing references I mentioned
just above. But if we judge that it would be an acceptable cost to
avoid the duplication, we could do it.
Add a self test for the new function.
Change-Id: I6173defb1e09856d137c1aa05ad51cbf521ea0b0 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 19 Sep 2025 20:27:02 +0000 (16:27 -0400)]
gdbsupport: use iterator range in parallel_for_each interface
I think it would be convenient for parallel_for_each to pass an
iterator_range to the worker function, instead of separate begin and end
parameters. This allows using a ranged for loop directly.
Change-Id: I8f9681da65b0eb00b738379dfd2f4dc6fb1ee612 Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 19 Sep 2025 20:27:00 +0000 (16:27 -0400)]
gdbsupport: use dynamic partitioning in gdb::parallel_for_each
gdb::parallel_for_each uses static partitioning of the workload, meaning
that each worker thread receives a similar number of work items. Change
it to use dynamic partitioning, where worker threads pull work items
from a shared work queue when they need to.
Note that gdb::parallel_for_each is currently only used for processing
minimal symbols in GDB. I am looking at improving the startup
performance of GDB, where the minimal symbol process is one step.
With static partitioning, there is a risk of workload imbalance if some
threads receive "easier" work than others. Some threads sit still while
others finish working on their share of the work. This is not
desirable, because the gdb::parallel_for_each takes as long as the
slowest thread takes.
When loading a file with a lot of minimal symbols (~600k) in GDB, with
"maint set per-command time on", I observe some imbalance:
Time for "minsyms install worker": wall 0.732, user 0.550, sys 0.041, user+sys 0.591, 80.7 % CPU
Time for "minsyms install worker": wall 0.881, user 0.722, sys 0.071, user+sys 0.793, 90.0 % CPU
Time for "minsyms install worker": wall 2.107, user 1.804, sys 0.147, user+sys 1.951, 92.6 % CPU
Time for "minsyms install worker": wall 2.351, user 2.003, sys 0.151, user+sys 2.154, 91.6 % CPU
Time for "minsyms install worker": wall 2.611, user 2.322, sys 0.235, user+sys 2.557, 97.9 % CPU
Time for "minsyms install worker": wall 3.074, user 2.729, sys 0.203, user+sys 2.932, 95.4 % CPU
Time for "minsyms install worker": wall 3.486, user 3.074, sys 0.260, user+sys 3.334, 95.6 % CPU
Time for "minsyms install worker": wall 3.927, user 3.475, sys 0.336, user+sys 3.811, 97.0 % CPU
^
----´
The fastest thread took 0.732 seconds to complete its work (and then sat
still), while the slowest took 3.927 seconds. This means the
parallel_for_each took a bit less than 4 seconds.
Even if the number of minimal symbols assigned to each worker is the
same, I suppose that some symbols (e.g. those that need demangling) take
longer to process, which could explain the imbalance.
With this patch, things are much more balanced:
Time for "minsym install worker": wall 2.807, user 2.222, sys 0.144, user+sys 2.366, 84.3 % CPU
Time for "minsym install worker": wall 2.808, user 2.073, sys 0.131, user+sys 2.204, 78.5 % CPU
Time for "minsym install worker": wall 2.804, user 1.994, sys 0.151, user+sys 2.145, 76.5 % CPU
Time for "minsym install worker": wall 2.808, user 1.977, sys 0.135, user+sys 2.112, 75.2 % CPU
Time for "minsym install worker": wall 2.808, user 2.061, sys 0.142, user+sys 2.203, 78.5 % CPU
Time for "minsym install worker": wall 2.809, user 2.012, sys 0.146, user+sys 2.158, 76.8 % CPU
Time for "minsym install worker": wall 2.809, user 2.178, sys 0.137, user+sys 2.315, 82.4 % CPU
Time for "minsym install worker": wall 2.820, user 2.141, sys 0.170, user+sys 2.311, 82.0 % CPU
^
----´
In this version, the parallel_for_each took about 2.8 seconds,
representing a reduction of ~1.2 seconds for this step. Not
life-changing, but it's still good I think.
Note that this patch helps when loading big programs. My go-to test
program for this is telegram-desktop that I built from source. For
small programs (including loading gdb itself), it makes no perceptible
difference.
Now the technical bits:
- One impact that this change has on the minimal symbol processing
specifically is that not all calls to compute_and_set_names (a
critical region guarded by a mutex) are done at the end of each
worker thread's task anymore.
Before this patch, each thread would compute the names and hash values for
all the minimal symbols it has been assigned, and then would call
compute_and_set_names for all of them, while holding the mutex (thus
preventing other threads from doing this same step).
With the shared work queue approach, each thread grabs a batch of of
minimal symbols, computes the names and hash values for them, and
then calls compute_and_set_names (with the mutex held) for this batch
only. It then repeats that until the work queue is empty.
There are therefore more small and spread out compute_and_set_names
critical sections, instead of just one per worker thread at the end.
Given that before this patch the work was not well balanced among worker
threads, I guess that threads would enter that critical region at
roughly different times, causing little contention.
In the "with this patch" results, the CPU utilization numbers are not
as good, suggesting that there is some contention. But I don't know
if it's contention due to the compute_and_set_names critical section
or the shared work queue critical section. That can be investigated
later. In any case, what ultimately counts is the wall time, which
improves.
- One choice I had to make was to decide how many work items (in this
case minimal symbols) each worker should pop when getting work from
the shared queue. The general wisdom is that:
- popping too few items, and the synchronization overhead becomes
significant, and the total processing time increases
- popping too many items, and we get some imbalance back, and the
total processing time increases again
I experimented using a dynamic batch size proportional to the number
of remaining work items. It worked well in some cases but not
always. So I decided to keep it simple, with a fixed batch size.
That can always be tweaked later.
- I want to still be able to use scoped_time_it to measure the time
that each worker thread spent working on the task. I find it really
handy when measuring the performance impact of changes.
Unfortunately, the current interface of gdb::parallel_for_each, which
receives a simple callback, is not well-suited for that, once I
introduce the dynamic partitioning. The callback would get called
once for each work item batch (multiple time for each worker thread),
so it's not possible to maintain a per-worker thread object for the
duration of the parallel for.
To allow this, I changed gdb::parallel_for_each to receive a worker
type as a template parameter. Each worker thread creates one local
instance of that type, and calls operator() on it for each work item
batch. By having a scoped_time_it object as a field of that worker,
we can get the timings per worker thread.
The drawbacks of this approach is that we must now define the
parallel task in a separate class and manually capture any context we
need as fields of that class.
Change-Id: Ibf1fea65c91f76a95b9ed8f706fd6fa5ef52d9cf Approved-By: Tom Tromey <tom@tromey.com>
Simon Marchi [Fri, 19 Sep 2025 20:26:59 +0000 (16:26 -0400)]
gdbsupport: re-work parallel_for_each test, again
I started working on this patch because I noticed that this
parallel_for_each test:
/* Check that if there are fewer tasks than threads, then we won't
end up with a null result. */
is not really checking anything. And then, this patch ended with
several changes, leading to general refactor of the whole file.
This test verifies, using std::all_of, that no entry in the intresults
vector is nullptr. However, nothing ever adds anything to intresults.
Since the vector is always empty, std::all_of is always true. This
state probably dates back to afdd1366358c ("Back out some
parallel_for_each features"), which removed the ability for
parallel_for_each to return a vector of results. That commit removed
some tests, but left this one in, I'm guessing as an oversight.
One good idea in this test is to check that the worker never receives
empty ranges. I think we should always test for that. I think it's
also a good idea to test with exactly one item, that's a good edge case.
To achieve this without adding some more code duplication, factor out
the core functionality of the test in yet another test_one function (I'm
running out of ideas for names). In there, check that the range
received by the worker is not empty. Doing this pointed out that the
worker is actually called with empty ranges in some cases, necessitating
some minor changes in parallel-for.h.
Then, instead of only checking that the sum of the ranges received by
worker functions is the right count, save the elements received as part
of those ranges (in a vector), and check that this vector contains each
expected element exactly once. This should make the test a bit more
robust (otherwise we could have the right number of calls, but on the
wrong items).
Then, a subsequent patch in this series changes the interface or
parallel_for_each to use iterator_range. The only hiccup is that it
doesn't really work if the "RandomIt" type of the parallel_for_each is
"int". iterator_range<int>::size wouldn't work, as std::distance
doesn't work on two ints. Fix this in the test right away by building
an std::vector<int> to use as input.
Finally, run the test with the default thread pool thread count in
addition to counts 0, 1 an 3, currently tested. I'm thinking that it
doesn't hurt to test parallel_for_each in the configuration that it's
actually used with.
Change-Id: I5adf3d61e6ffe3bc249996660f0a34b281490d54 Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Tue, 30 Sep 2025 19:32:50 +0000 (21:32 +0200)]
[gdb/testsuite, tclint] Further tclint fixing
Currently stable tclint (v6.0.1) as used in pre-commit doesn't check code that
is passed as arguments to commands specific to the gdb testsuite [1], like
with_test_prefix:
...
with_test_prefix foo {
...
}
...
I wrote a rudimentary tclint patch handling this, skipping the dwarf assembler
procs.
Tom de Vries [Tue, 30 Sep 2025 16:45:44 +0000 (18:45 +0200)]
[pre-commit] Set default_stages to pre-commit
I realized I was seeing the newly added tclint check twice:
...
$ touch gdb/testsuite/gdb.base/foo.exp
$ git add gdb/testsuite/gdb.base/foo.exp
$ git commit -a -m foo 2>&1 | grep tclint
tclint..................................................................Passed
tclint..............................................(no files to check)Skipped
$
...
The hook is run once for stage pre-commit, and once for stage commit-msg.
Since the hook doesn't specify a stage at which it's supposed to be run, it
takes its default from default_stages, which defaults to all stages.
Fix this by setting default_stages to pre-commit:
...
$ git commit -a -m foo 2>&1 | grep tclint
tclint..................................................................Passed
$
...
The only hook sofar that needs a different stage than pre-commit is
codespell-log, and it's not affected by this change because it has an explicit
"stages: [commit-msg]" setting.
Tom Tromey [Fri, 4 Apr 2025 04:13:00 +0000 (22:13 -0600)]
Fix bug in gdb.lookup_type
gdb.lookup_type accepts a 'block' argument, but in some cases does not
use it. This can cause the wrong type to be returned.
This patch fixes the problem by simply passing the block through. I
have no idea why it worked the way it did, and there weren't any tests
for the 'block' parameter. (I didn't look at git blame out of fear
that it was my patch back in the day.)
Tom de Vries [Tue, 30 Sep 2025 13:36:05 +0000 (15:36 +0200)]
[gdb/testsuite] Fix gdb.tui/pr30056.exp arrow right test
On aarch64-linux, I run into:
...
FAIL: gdb.tui/pr30056.exp: arrow right
...
because while the intention is to observe the change from:
...
| 20 main (void) |
...
into:
...
| 20 ain (void) |
...
we're actually looking at another line.
Fix this by looking at the contents of the entire source window.
Andrew Burgess [Thu, 29 Sep 2022 11:45:26 +0000 (12:45 +0100)]
gdb: some process_stratum_target should not be shared
When multi-target support was added to GDB, an assumption was made
that all process_stratum_target sub-classes could be shared by
multiple inferiors.
For things like the Linux and FreeBSD native targets, this is
absolutely true (or was made true). But some targets were either not
updated, or, due to design restrictions, cannot be shared.
This patch adds a target_ops::is_shareable member function. When this
returns false then this indicates that an instance of a particular
target should only appear on a single target stack. It is fine for
difference instances of a single target type to appear on different
target stacks though.
This is my second attempt at this patch. The first attempt can be
found here:
The initial approach was to have all targets be shareable by default,
and to then mark those targets which I knew were problematic.
Specifically, the only target I was interested in was core_target,
which cannot be shared (details below). During review Tom pointed out:
I think there are a lot of other targets that can't be
shared... remote-sim, all the trace targets, even I think windows-nat,
since it isn't multi-inferior-capable yet.
The suggestion was that the default should be that targets were NOT
shareable, and we should then mark those targets which we know can be
shared. That is the big change in this iteration of the patch.
The core_target is still non-shareable. This target stores state
relating to the open core file in the core_target and in the current
inferior's program_space. After an 'add-inferior' command, if we
share the core_target, the new inferior will have its own
program_space, but will share the core_target with the original
inferior. This leaves the new inferior in an unexpected state where
the core BFD (from the new program_space) is NULL. Attempting to make
use of the second inferior, e.g. to load a new executable, will (on
x86 at least) cause GDB to crash as it is not expecting the core BFD
to be NULL.
I am working to move the core file BFD into core_target, at which
point it might be possible to share the core_target, though I'm still
not entirely sure this makes sense; loading a core file will in many
cases, automatically set the executable in the program_space, creating
a new inferior would share the core_target, but the new inferior's
program space would not have the executable loaded. But I figure we
can worry about this another day because ....
As Tom pointed out in his review of V1, there are other targets that
should be non-shareable (see quote above). In addition, I believe
that the remote target can only be shared in some specific situations,
the 'add-inferior' case is one where the 'remote' target should NOT be
shared.
The 'remote' (not 'extended-remote') target doesn't allow new
inferior's to be started, you need to connect to an already running
target. As such, it doesn't really make sense to allow a 'remote'
target to be shared over an 'add-inferior' call, what would the user
do with the new inferior? They cannot start a new process. They're
not debugging the same process as the original inferior. This just
leaves GDB in a weird state.
However, 'remote' targets are a little weird in that, if the remote
inferior forks, and GDB is set to follow both the parent and the
child, then it does make sense to allow sharing. In this case the new
inferior is automatically connected to the already running child
process.
So when we consider 'add-inferior' there are two things we need to
consider:
1. Can the target be shared at all? The new target_ops::is_shareable
function tells us this.
2. Can the target be used to start a new inferior? The existing
target_ops::can_create_inferior function tells us this.
If the process_stratum_target returns true for both of these functions
then it is OK to share it across an 'add-inferior' call. If either
returns false then the target should not be shared.
When pushing a target onto an inferior's target stack, we only need to
consider target_ops::is_shareable, only shareable targets should be
pushed onto multiple target stacks.
The new target_ops::is_shareable function returns true as its default,
all the immediate sub-classes are shareable.
However, this is overridden in process_stratum_target::is_shareable, to
return false. All process_stratum_target sub-classes are non-shareable
by default.
Finally, linux_nat_target, fbsd_nat_target, and remote_target, are all
marked as shareable. This leaves all other process_stratum_target
sub-classes non-shareable.
I did some very light testing on Windows, and I don't believe that this
target supports multiple inferiors, but I could easily be wrong here.
My windows testing setup is really iffy, and I'm not 100% sure if I did
this right.
But for the Windows target, and any of the others, if this commit breaks
existing multi-inferior support, then the fix is as simple as adding an
is_shareable member function that returns true.
If the user tries to 'add-inferior' from an inferior with a
non-shareable target, or the 'remote' target as it cannot start new
inferiors, then they will get a warning, and the new inferior will be
created without a connection.
If the user explicitly asks for the new inferior to be created without
a connection, then no warning will be given.
At this point the user is free to setup the new inferior connection as
they see fit.
I've updated the docs, and added a NEWS entry for the new warning. In
the docs for clone-inferior I've added reference to -no-connection,
which was previously missing.
Some tests needed fixing with this change, these were
gdb.base/quit-live.exp, gdb.mi/mi-add-inferior.exp,
gdb.mi/new-ui-mi-sync.exp, and gdb.python/py-connection-removed.exp. In
all cases, when using the native-gdbserver board, these tests tried to
create a new inferior, and expected the new inferior to start sharing
the connection with the original inferior. None of these tests actually
tried to run anything in the new inferior, if they did then they would
have discovered that the new inferior wasn't really sharing a
connection. All the tests have been updated to understand that for
'remote' connections (not 'extended-remote') the connection will not be
shared. These fixes are all pretty simple.
While compilers default to v8plus on 32-bit Solaris/SPARC (gcc at least
since 4.4 in 2009, cc since at least Stdio 9 in 2010), gas still uses a
sparclite default. While this doesn't cause issue for gcc (it passes
-Av8plus as necessary), it repeatedly lead to problems in the testsuite
which has to be sprinkled with setting ASFLAGS accordingly since gas cannot
assemble the gcc output by default.
This patch switches the default to v8plus on Solaris to match gcc.
I had to introduce a new arch value, v8plus-32, matching v9-64, to allow
for this.
I cannot reliably tell if other SPARC targets are similarly affected, so
this patch restricts the change to Solaris.
Tested on sparc-sun-solaris2.11 and sparcv9-sun-solaris2.11.
gas:
* config/tc-sparc.c (sparc_arch_table): Introduce v8plus-32.
* configure.tgt (generic_target) <sparc-*-solaris*>: Set arch to
v8plus-32 for 32-bit sparc.
* testsuite/gas/sparc/v8plus.rd, testsuite/gas/sparc/v8plus.s: New
test.
* testsuite/gas/sparc/sparc.exp: Run it on sparc*-*-solaris2*.
When building with -DDEBUG=2, bfd doesn't compile:
In file included from bfd/elfcode.h:2051,
from bfd/elf32.c:23:
bfd/elfcore.h: In function ‘_bfd_elf32_core_find_build_id’:
bfd/elfcore.h:354:3: error: implicit declaration of function ‘elf_debug_file’; did you mean ‘elf_debug_section’? [-Wimplicit-function-declaration]
354 | elf_debug_file (&i_ehdr);
| ^~~~~~~~~~~~~~
| elf_debug_section
This happens because a guard in elfcore.h doesn't match the others.
This patch fixes this, allowing the build to complete.
H.J. Lu [Fri, 26 Sep 2025 00:03:01 +0000 (08:03 +0800)]
binutils: Pass target plugin file to target ar/nm/ranlib
There are 2 kinds of binutils tests:
1. Tests of binutils object files and libraries using the build tools,
like CC, AR, NM and RANLIB.
2. Tests of binutils programs as the target tools, like CC_FOR_TARGET,
AR_FOR_TARGET, NM_FOR_TARGET and RANLIB_FOR_TARGET.
Set AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET and
RANLIB_PLUGIN_OPTION_FOR_TARGET to the target compiler plugin file for
target ar/nm/ranlib.
PR binutils/33483
* Makefile.in: Regenerated.
* configure: Likewise.
* Makefile.tpl (AR_FOR_TARGET): Add @AR_PLUGIN_OPTION_FOR_TARGET@.
(NM_FOR_TARGET): Add @NM_PLUGIN_OPTION_FOR_TARGET@.
(RANLIB_FOR_TARGET): Add @RANLIB_PLUGIN_OPTION_FOR_TARGET@.
* configure.ac: Use CLANG_PLUGIN_FILE_FOR_TARGET and
GCC_PLUGIN_OPTION_FOR_TARGET to set AR_PLUGIN_OPTION_FOR_TARGET,
NM_PLUGIN_OPTION_FOR_TARGET and RANLIB_PLUGIN_OPTION_FOR_TARGET.
AC_SUBST AR_PLUGIN_OPTION_FOR_TARGET, NM_PLUGIN_OPTION_FOR_TARGET
and RANLIB_PLUGIN_OPTION_FOR_TARGET.
Tom de Vries [Fri, 26 Sep 2025 23:54:18 +0000 (01:54 +0200)]
[gdb/testsuite] Drop tclsh dependency
The test-case gdb.tui/tuiterm-2.exp uses a tcl script gdb.tcl that uses tclsh
as its interpreter:
...
#!/usr/bin/env tclsh
...
I used tclsh because I assumed it was an existing dependency of
dejagnu/expect, but apparently [1] that's not the case.
IWBN to use some existing dependency instead.
Using expect instead of tclsh also works on my system, but looking in
/usr/bin/runtest I realized that someone might have a dejagnu setup with
a custom expect indicated by setting an env var EXPECT. So to find expect
we'd have to mimic whatever runtest is doing to find expect, or do:
...
$ runtest --version -v | grep "Expect binary"
...
using the appropriate runtest.
That sounds non-trivial and fragile, so simply use a shell script with /bin/sh
interpreter instead.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2025-September/220736.html
Tom de Vries [Fri, 26 Sep 2025 23:20:56 +0000 (01:20 +0200)]
[gdb/testsuite] Handle wrap mode unsupported in gdb.tui/wrap-line.exp
When running test-case gdb.tui/wrap-line.exp on msys2-ucrt64, we run into some
fails in the CLI part of the test-case because:
...
(gdb) maint info screen
...
Readline wrapping mode: unsupported (terminal is not Cursor Up capable)
...
Fix this by requiring wrapping mode "readline" for that part of the test-case.
Tom de Vries [Fri, 26 Sep 2025 23:20:56 +0000 (01:20 +0200)]
[gdb/testsuite] Fix timeout in gdb.tui/wrap-line.exp
When running test-case gdb.tui/wrap-line.exp on msys2-ucrt64, I run into a
timeout here:
...
set test "startup prompt"
gdb_test_multiple "" $test {
-re "^$gdb_prompt $" {
pass "$test"
}
}
...
due to running into "^[[6n(gdb) ".
Fix this by allowing this, similar to how this was fixed in default_gdb_start by
commit 7e1964f9c61 ("[gdb/testsuite] Set TERM to dumb by default").
Tom de Vries [Fri, 26 Sep 2025 23:13:16 +0000 (01:13 +0200)]
[gdb/testsuite] Improve gdb.tui/pr30056.exp
Fix a few things I noticed while working on test-case gdb.tui/pr30056.exp:
- unnecessary indentation due to save_vars
- missing gdb_assert checking the result of Term::wait_for_region_contents
- redundant comment "Uncomment this to simulate that PR cli/30498 is fixed"
Tom de Vries [Fri, 26 Sep 2025 23:13:16 +0000 (01:13 +0200)]
[gdb/testsuite] Remove wait in gdb.tui/pr30056.exp
In test-case gdb.tui/pr30056.exp, we have:
...
# Send arrow-right.
send_gdb "\033\[C"
# We need the arrow-right to be processed by readline, before we
# send the following ^C. Waiting 1 ms seems to do that.
after 1
...
Waiting for an effect by sleeping is fragile.
The reason we're doing so is that we're waiting for an effect that is not
visible: the arrow-right is meant to horizontally scroll the source window,
but since there's no source, nothing happens.
Fix this by using an executable in the test-case, with a source file
containing a comment long enough to make horizontal scrolling possible.
Fixing this means we no longer run into PR33371, so that PR will need its own
test-case.
Tom Tromey [Wed, 3 Sep 2025 15:26:25 +0000 (09:26 -0600)]
Always propagate exceptions in DAP
This changes the DAP exec_and_log function to always transform an
exception into a DAPException and propagate it.
As the bug points out, we haven't always wrapped calls when
appropriate. I think it's better to cause the request to fail by
default; if any spot truly needs to ignore errors, that is readily
done at the point of call.
Tom Tromey [Wed, 3 Sep 2025 15:08:01 +0000 (09:08 -0600)]
Remove Invoker class from DAP
The Invoker used to be more convenient, before DAP requests were run
on the gdb thread by default. Now it is barely used and easily
replaced by a couple of lambdas.
Tom Tromey [Wed, 3 Sep 2025 17:54:57 +0000 (11:54 -0600)]
Fix minor bug in dap-support.exp
Commit faee137249c8 refactored dap-support.exp, but accidentally left
a reference to a variable that was renamed. I noticed this when an
earlier version of this series provoked one of the errors in this
code.
The second line of this code is probably a bug because it does nothing. It
was probably supposed to update "file->all_comp_units_without_ranges" to point
to "each" - the new head of the list.
Jan Beulich [Fri, 26 Sep 2025 10:21:11 +0000 (12:21 +0200)]
Dwarf: adjust fetch_indirect{,_line}_string()'s return type
As already is the case for fetch_indexed_string() and
fetch_alt_indirect_string(), have them return a pointer to plain char,
properly compatible with e.g. the %s format specifier that the return
values are used with in several cases. This way no casts at call sites are
necessary, and several (bogus) ones in the functions can be exchanged for
just one each. Some other constification is needed elsewhere, now that
const-ness isn't being cast away anymore.
PowerPC: Fix typo in PowerPC note pseudo-section names
The recent tidy-up commit 09e56f0515c3 ("Code tidy: bfd/elf.c:
Tidy up core note handling code.") introduced regressions in the
PowerPC core note handling. The pseudo-section names for TM_CVSX,
TM_SPR, VSX and VMX notes were defined with an underscore instead of a
hyphen, breaking GDB test cases. The same goes for one riscv and one
s390 define.
This patch restores the correct section names by using hyphens in the
definitions, fixing 897 GDB test failures on PowerPC.
bfd/
* elf.c: (NOTE_PSEUDO_SECTION_PPC_TM_CVSX),
(NOTE_PSEUDO_SECTION_PPC_TM_SPR, NOTE_PSEUDO_SECTION_PPC_VSX),
(NOTE_PSEUDO_SECTION_PPC_VMX, NOTE_PSEUDO_SECTION_RISCV_CSR),
(NOTE_PSEUDO_SECTION_S390_CTRS): Use hyphens in section names
instead of underscores.
Andrew Burgess [Thu, 25 Sep 2025 09:13:45 +0000 (10:13 +0100)]
gdb/doc: be more verbose about .gdb_index changes in version 9
I had reason to read the docs relating to .gdb_index format, and ended
up having to look at historical versions of the documentation in order
to clarify exactly what changed with the introduction of version 9.
Given that we claim versions 7, 8, and 9 are all still allowable index
versions, I think our docs should make it clear what the current
format is, but also what previous formats looked like.
I did try to do the same for the changes from 7 to 8, but even after
reading commit 796a7ff8234cfaa8a I'm still not entirely clear what
changed. If I gain some insight in the future then there might be a
follow on patch for that too.
Bruce McCulloch [Fri, 1 Nov 2024 16:31:46 +0000 (12:31 -0400)]
libctf: dump CTF array dimensions in the right order
Before GCC PR114186, all looked good in the land of
multidimensional arrays: you wrote
int a[5][10];
and ctf_type_aname() et al would print it as
int [5][10]
Unfortunately this was two bugs in one. GCC was emitting the array as if
it were int a[10][5], i.e. as this:
a -> [10] -> [5] -> int
rather than
a -> [5] -> [10] -> int
as it should be. libctf was hiding this by printing them in the wrong
order, concealing the bug from anyone using objdump --ctf or anything
but actual type graph traversal. Once this was fixed for GCC, the bug
was visible in libctf: multidimensional arrays were printed backwards!
(But this is just a print-time bug: the underlying bug, that something
traversing the type graph would see the array in backwards order, was
fixed by the fix to GCC.)
Fix this libctf bug, printing the arrays the right way round. In a
possibly futile attempt to retain some vestige of backwards
compatibility, introduce a new bug-compat flag CTF_F_ARRNELEMS, which,
if on, indicates that PR114186 is fixed and GCC is emitting array
elements the right way round. (Unfortunately, the fix went in without
this flag, so some GCCs will still emit CTF that will cause libctf to
print them wrong, even with this fix -- but it's no wronger than it was
before, and new GCC and new binutils, as well as GCC older than any fix
for PR114186 and new binutils, will print things properly. Someone
traversing the type graph will see things right after the GCC fix, wrong
before it, and there isn't really any reliable way to tell which you
have, though if CTF_F_ARRNELEMS is set, you definitely have a fixed GCC.
The test checks for this, but it's not something we expect actual users
to ever do -- CTF dict flags are an internal implementation detail with
no user-visible API for a reason.)
[nca: log message, test compat with older compilers]
include/
* ctf.h (CTF_F_ARRNELEMS): New bug-compat flag.
(CTF_F_MAX): Adjust.
libctf/
PR libctf/32161
* ctf-decl.c (ctf_decl_push): Prepend if this is an array and
the bug-compat flag is set.
* ctf-dump.c (ctf_dump_header): Dump the new bug-compat flag.
* testsuite/libctf-lookup/multidim-array*: New test.
Nick Alcock [Mon, 22 Sep 2025 20:07:11 +0000 (21:07 +0100)]
libctf: fix querying of large structures
After GCC PR 121411 is fixed, large structures (with offsets > 512MiB)
are written correctly... but libctf cannot query them properly unless
they are even bigger (> 4GiB), because it checks to see if the ctt_size
is CTF_LSIZE_SENT to decide whether to use a ctf_lmember_t or a
ctf_member_t to encode the structure members. But the structure member
offsets are in *bits*, not bytes: the right value to check is
CTF_LSTRUCT_THRESH, which is 1/8th the size.
(Thanks to Martin Pirker <martin.pirker1@chello.at> for the diagnosis
and fix.)
Testing this is a bit fun, because we don't want to emit an error if the
compiler is broken: but we cannot tell whether the compiler is broken
using the existing lookup harness, because its input is passed through
the linker (and thus the broken ld). So add another sort of link mode,
"objects", which keeps the constituent object files around and passes
both the final linker output and the object files that make it up to the
lookup program. Our testcase can then check the linker input to see if
the compiler is buggy, and only if it isn't check the linker output and
fail if things aren't right.
libctf/
PR libctf/33339
* ctf-types.c (ctf_struct_member): Check CTF_LSTRUCT_THRESH, not
CTF_LSIZE_SENT.
* testsuite/lib/ctf-lib.exp (run_lookup_test): New 'objects'
link option.
* testsuite/libctf-lookup/big-struct-corruption.*: New test.
* testsuite/libctf-lookup/big-struct-ctf.c: New test input.
H.J. Lu [Mon, 22 Sep 2025 20:24:00 +0000 (04:24 +0800)]
Binutils/GCC: Add clang LTO support to AR, NM and RANLIB
Add CLANG_PLUGIN_FILE to find the clang plugin file and pass it to
--plugin for ar, nm and ranlib so that binutils can be built with
clang LTO. Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION since
GCC_PLUGIN_OPTION may return the wrong PLUGIN_OPTION with clang.
PR binutils/33470
* Makefile.in: Regenerated.
* Makefile.tpl (NM): Add @NM_PLUGIN_OPTION@.
* configure: Regenerated.
* configure.ac: Include config/clang-plugin.m4.
Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION to set
PLUGIN_OPTION. Set and subst NM_PLUGIN_OPTION.
* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Use CLANG_PLUGIN_FILE and
GCC_PLUGIN_OPTION.
PR binutils/33470
* aclocal.m4: Regenerated.
* configure: Likewise.
* configure.ac: Move GCC_PLUGIN_OPTION after GCC_NO_EXECUTABLES.
Run CLANG_PLUGIN_FILE before GCC_PLUGIN_OPTION to set
PLUGIN_OPTION. Don't add the redundant --plugin option.
PR ld/33456
* elflink.c (elf_link_add_object_symbols): Move new check later
to give the backend add_symbol_hook a chance to remove symbols
with empty names.
Alan Modra [Wed, 24 Sep 2025 22:52:24 +0000 (08:22 +0930)]
PR 33452 SEGV in bfd_elf_gc_record_vtentry
Limit addends on vtentry relocs, otherwise ld might attempt to
allocate a stupidly large array. This also fixes the expression
overflow leading to pr33452. A vtable of 33M entries on a 64-bit
host is surely large enough, especially considering that VTINHERIT
and VTENTRY relocations are to support -fvtable-gc that disappeared
from gcc over 20 years ago.
Andrew Burgess [Wed, 10 Sep 2025 13:54:21 +0000 (14:54 +0100)]
gdb/linux: consider ptrace_scope when building attach error message
On GNU/Linux, if an attach fails, then we end up calling
linux_ptrace_attach_fail_reason, which returns a string describing why
the attach might have failed.
This commit extends linux_ptrace_attach_fail_reason to check the
current /proc/sys/kernel/yama/ptrace_scope setting. When this is set
to a value greater than 0 attaching can be restricted in some cases.
If I first set ptrace_scope to 1, like this:
$ echo 1 | sudo tee /proc/sys/kernel/yama/ptrace_scope
Then use current master GDB to attach to a process, I see this:
(gdb) attach 2476518
Attaching to process 2476518
ptrace: Operation not permitted.
(gdb)
With this patch applied the output becomes:
(gdb) attach 2476518
Attaching to process 2476518
warning: the /proc/sys/kernel/yama/ptrace_scope setting of 1 might prevent attaching, see 'man 2 ptrace'
ptrace: Operation not permitted.
(gdb)
In my (limited) experience, not every user is familiar with the
ptrace_scope setting. Finding that attach just doesn't work often
leads users to believe that the only way to have GDB attach to another
process is to run GDB as root.
Though that is a solution to the problem, my hope is that, by giving
the users more information, they can make a more informed choice about
which solution is right for them (e.g. run as root, change the
setting, start the inferior directly under GDB, etc).
This change also works for gdbserver. For example:
(gdb) target extended-remote :54321
Remote debugging using :54321
(gdb) attach 2475389
Attaching to process 2475389
Attaching to process 2475389 failed: Cannot attach to process 2475389: \
Operation not permitted (1), the /proc/sys/kernel/yama/ptrace_scope \
setting of 1 might prevent attaching, see 'man 2 ptrace'
(gdb)
There's no test for this as testing would require adjusting a system
wide setting.
I've linked to a semi-related bug. It is discussing the same issue at
least. This patch doesn't try to "fix" anything that the bug is
talking about, it just makes it (I think) slightly clearer when the
issue does arise.
Timur Golubovich [Thu, 28 Aug 2025 17:12:55 +0000 (20:12 +0300)]
This commit adds support for catching syscalls on riscv
It affects following files:
- gdb/riscv-linux-tdep.c: a function to get syscall number.
- gdbserver/linux-riscv-low.cc: syscall trapinfo function to enable
catching syscalls on remote targets.
- gdb/syscalls/riscv-linux.xml.in: a file with syscalls, generated from
linux kernel sources using gdb/syscalls/update-linux-from-src.sh script.
- gdb/syscalls/riscv-linux.xml: a file with syscalls, patched with group
names gdb/syscalls/apply-defaults.xsl using xsltproc tool.
- gdb/syscalls/update-linux.sh: set startyear to 2025 on riscv.
- gdb/syscalls/update-linux-from-src.sh: riscv syscall table must be
generated from kernel headers.
- gdb/NEWS: catch-syscall feature is now available on riscv.
- gdb/data-directory/Makefile.in: adding file with syscalls to Makefile.
Stephan Rohr [Wed, 20 Aug 2025 13:06:23 +0000 (06:06 -0700)]
gdb: resolve type to target_type in expression evaluation
If an expression is evaluated with 'EVAL_AVOID_SIDE_EFFECTS', we're
essentially interested in compatibility of the operands. If there is an
operand of reference type, this would give us a memory value that would
cause a failure if GDB attempts to access the contents.
GDB fails to evaluate binary expressions for the following example:
Expression evaluation uses helper functions such as 'value_equal',
'value_logical_not', etc. These helper functions do not take a 'noside'
argument and if one of their value arguments was created from a function
call that returns a reference type when noside == EVAL_AVOID_SIDE_EFFECTS,
GDB attempts to read from an invalid memory location. Consider the
following call stack of the 'ptype v_struct.get () + 1' command at the time
of assertion when the memory error is raised:
#0 memory_error (err=TARGET_XFER_E_IO, memaddr=0) at gdb/corefile.c:114
#1 read_value_memory (val=.., bit_offset=0, stack=false, memaddr=0,
buffer=.. "", length=4) at gdb/valops.c:1075
#2 value::fetch_lazy_memory (this=..) at gdb/value.c:3996
#3 value::fetch_lazy (this=..) at gdb/value.c:4135
#4 value::contents_writeable (this=..) at gdb/value.c:1329
#5 value::contents (this=..) at gdb/value.c:1319
#6 value_as_mpz (val=..) at gdb/value.c:2685
#7 scalar_binop (arg1=.., arg2=.., op=BINOP_ADD) at gdb/valarith.c:1240
#8 value_binop (arg1=.., arg2=.., op=BINOP_ADD) at gdb/valarith.c:1489
#9 eval_op_add (expect_type=0x0, exp=.., noside=EVAL_AVOID_SIDE_EFFECTS,
arg1=.., arg2=..) at gdb/eval.c:1333
#10 expr::add_operation::evaluate (this=.., expect_type=0x0, exp=..,
noside=EVAL_AVOID_SIDE_EFFECTS) at gdb/expop.h:1209
#11 expression::evaluate (this=.., expect_type=0x0,
noside=EVAL_AVOID_SIDE_EFFECTS) at gdb/eval.c:110
#12 expression::evaluate_type (this=..) at gdb/expression.h:242
'add_operation::evaluate' calls the helper 'eval_op_add' which attempts
to read from the unresolved memory location. Convert to the target type
to avoid such problems. The patch is implemented in 'expop.h' for the
following reasons:
* Support templated classes without explicit helpers, e.g.,
'binop_operation' and 'comparison_operation'.
* Stripping references in 'binop_promote' requires additional
refactoring beyond this patch as we would need to carry on the
'noside' parameter.
The above failures are resolved with the patch:
(gdb) print v_struct.get () == 1 && v_struct3.get () == 2
$1 = false
(gdb) print v_struct.get () == 1 || v_struct3.get () == 2
$2 = true
(gdb) ptype v_struct.get ()
type = int &
(gdb) ptype v_struct.get () == 1
type = bool
(gdb) ptype v_struct.get () + 1
type = int
(gdb) ptype v_struct.get () && 1
type = bool
(gdb) ptype v_struct.get () || 1
type = bool
(gdb) ptype !v_struct.get ()
type = bool
(gdb) ptype v_struct.get () ? 2 : 3
type = int
(gdb) ptype v_struct.get () | 1
type = int
Co-Authored-By: Tankut Baris Aktemur <tankut.baris.aktemur@intel.com> Approved-By: Tom Tromey <tom@tromey.com>
Tom de Vries [Wed, 24 Sep 2025 07:57:25 +0000 (09:57 +0200)]
[gdb/testsuite] Fix gdb.tui/tui-layout-asm-short-prog.exp on cygwin
On x86_64-cygwin, I run into:
...
Running tui-layout-asm-short-prog.exp ...
gdb compile failed, tui-layout-asm-short-prog.S: Assembler messages:
tui-layout-asm-short-prog.S:26: Error: \
junk at end of line, first unrecognized character is `-'
=== gdb Summary ===
# of untested testcases 1
...
This is due to this note in gdb.tui/tui-layout-asm-short-prog.S:
...
.section .note.GNU-stack,"",@progbits
...
The note can be easily skipped for cygwin, but after doing so, we run into a
fail.
The problem is that while the test-case tries to generate 5 nops:
...
.rept 5
nop
.endr
...
in fact 16 nops are generated.
The fail is not specific to x86_64-cygwin, if we do ".rept 16" on
x86_64-linux, we get the same fail.
Fix this by increasing the "large" scroll amounts from 13 to 15.
H.J. Lu [Tue, 23 Sep 2025 00:52:26 +0000 (08:52 +0800)]
elf: Return error on unsorted symbol table if not allowed
Normally ELF symbol table should be sorted, i.e., local symbols precede
global symbols. Irix 6 is an exception and its elf_bad_symtab is set
to true. Issue an error if elf_bad_symtab is false and symbol table is
unsorted.
PR ld/33450
* elflink.c (set_symbol_value): Change return type to bool and
return false on error. Issue an error on unsorted symbol table
if not allowed.
(elf_link_input_bfd): Return false if set_symbol_value reurns
false.
Alice Carlotti [Tue, 2 Sep 2025 15:30:16 +0000 (16:30 +0100)]
aarch64: Remove unused feature bits
Many feature bits were unnecessarily added for features with no command
line flags, and effectively acted as aliases of the architecture version
bit they were linked to. The system register regating patch removed all
uses of these feature bits, so we can just remove them.
Alice Carlotti [Tue, 2 Sep 2025 14:45:39 +0000 (15:45 +0100)]
aarch64: Update system register gating
Historically we have been inconsistent and overly restrictive in our
choice of features to gate system register accesses. (Originally this
gating was always applied, but now it is disabled unless the
--menable-sysreg-checking option is specified).
This patch updates these constraints, following the principle that we
should only reject a system register access if it requires some
architecture feature or version whose corresponding command line
extension has not been enabled.
The most common change in this patch concerns system registers that
were:
- part of a feature FEAT_X with no corresponding command line extension;
- introduced in a newer architecture version ArmvX.Z;
- permitted to be implemented from an earlier version ArmvX.Y.
Previously these system registers tended to be gated on ArmvX.Z or left
ungated, but following the above principle they are now gated on ArmvX.Y
instead.
Alice Carlotti [Tue, 2 Sep 2025 16:46:01 +0000 (17:46 +0100)]
aarch64: Remove CSRE system registers
Most support for CSRE was removed from Binutils in 2021 after it was
removed from the architecture. This patch removes the remaining system
registers and test files.
Alice Carlotti [Tue, 2 Sep 2025 14:49:40 +0000 (15:49 +0100)]
aarch64: Make spmzr_el0 write-only
Remove all test cases that expect spmzr_el0 to be readable, and remove
some redundant default macro values from armv9_5-a-sysregs.s while we're
there.
Add a read of spmzr_el0 to sysreg-diagnostics.s. This turns out to be
the first test for the "reading from a write-only register" note.
Also remove the recently added -menable-sysreg-checking option from this
test, both to simplify the addition of spmzr_el0 to the test, and to
verify that read/write diagnostics don't depend on that option.
Alice Carlotti [Tue, 2 Sep 2025 14:11:24 +0000 (15:11 +0100)]
aarch64: Remove F_ARCHEXT flag
The flag is unnecessary, because we can just unconditionally check the
features field every time. Having the information duplicated in two
separate fields makes it harder to maintain, particularly in the context
of the upcoming regating patch.
The reg_flags parameter of aarch64_sys_ins_reg_supported_p is now
unused, so remove that as well.
#5 0x000055a21da8a880 in internal_vproblem(internal_problem *, const char *, int, const char *, typedef __va_list_tag __va_list_tag *) (problem=problem@entry=0x55a21e289060 <internal_error_problem>, file=<optimized out>, line=<optimized out>, fmt=<optimized out>, ap=ap@entry=0x7ffec7576be0) at ../../gdb/utils.c:477
#6 0x000055a21da8aadf in internal_verror (file=<optimized out>, line=<optimized out>, fmt=<optimized out>, ap=ap@entry=0x7ffec7576be0) at ../../gdb/utils.c:503
#7 0x000055a21dcbd055 in internal_error_loc (file=file@entry=0x55a21dd33b71 "../../gdb/regcache.c", line=line@entry=432, fmt=<optimized out>) at ../../gdbsupport/errors.cc:57
#8 0x000055a21d8baaa9 in get_thread_regcache (thread=thread@entry=0x55a258de3a50) at ../../gdb/regcache.c:432
#9 0x000055a21d74fa18 in print_signal_received_reason (uiout=0x55a258b649b0, siggnal=GDB_SIGNAL_TRAP) at ../../gdb/infrun.c:9287
#10 0x000055a21d7daad9 in mi_interp::on_signal_received (this=0x55a258af5f60, siggnal=GDB_SIGNAL_TRAP) at ../../gdb/mi/mi-interp.c:372
#11 0x000055a21d76ef99 in interps_notify<void (interp::*)(gdb_signal), gdb_signal&> (method=&virtual table offset 88, this adjustment 974682) at ../../gdb/interps.c:369
#12 0x000055a21d76e58f in interps_notify_signal_received (sig=<optimized out>, sig@entry=GDB_SIGNAL_TRAP) at ../../gdb/interps.c:378
#13 0x000055a21d75074d in notify_signal_received (sig=GDB_SIGNAL_TRAP) at ../../gdb/infrun.c:6818
#14 0x000055a21d755af0 in normal_stop () at ../../gdb/gdbthread.h:432
#15 0x000055a21d768331 in fetch_inferior_event () at ../../gdb/infrun.c:4753
The user is using a build of GDB with 32-bit ARM support included, and
they gave the following description for what they were doing at the
time of the crash:
Suspended the execution of the firmware in Eclipse. The gdb was
connected to JLinkGDBServer with activated FreeRTOS awareness JLink
plugin.
So they are remote debugging with a non-gdbserver target.
Looking in normal_stop() we see this code:
/* As we're presenting a stop, and potentially removing breakpoints,
update the thread list so we can tell whether there are threads
running on the target. With target remote, for example, we can
only learn about new threads when we explicitly update the thread
list. Do this before notifying the interpreters about signal
stops, end of stepping ranges, etc., so that the "new thread"
output is emitted before e.g., "Program received signal FOO",
instead of after. */
update_thread_list ();
Which accounts for the transition from frame #14 to frame #13. But it
is the update_thread_list() call which interests me. This call asks
the target (remote target in this case) for the current thread list,
and then marks threads exited based on the answer.
And so, if a (badly behaved) target (incorrectly) removes a thread
from the thread list, then the update_thread_list() call will mark the
impacted thread as exited, even if GDB is currently handling a signal
stop event for that target.
My guess for what's going on here then is this:
1. Thread receives a signal.
2. Remote target sends GDB a stop with signal packet.
3. Remote decides that the thread is going away soon, and marks the
thread as exited.
4. GDB asks for the thread list.
5. Remote sends back the thread list, which doesn't include the
event thread, as the remote things this thread has exited.
6. GDB marks the thread as exited, and then proceeds to try and
print the signal stop event for the event thread.
7. Printing the signal stop requires reading registers, which
requires a regache. We can only get a regcache for a non-exited
thread, and so GDB raises an assertion.
Using the gdbreplay test frame work I was able to reproduce this
failure using gdbserver. I create an inferior with two threads, the
main thread sends a signal to the second thread, GDB sees the signal
arrive and prints this information for the user.
Having captured the trace of this activity, I then find the thread
list reply in the log file, and modify it to remove the second thread.
Now, when I replay the modified log file I see the same assertion
complaining about an attempt to get a regcache for an exited thread.
I'm not entirely sure the best way to fix this. Clearly the problem
here is a bad remote target. But, replies from a remote target
should (in my opinion) not be considered trusted, as a consequence, we
should not be asserting based on data coming from a remote. Instead,
we should be giving warnings or errors and have GDB handle the bad
data as best it can.
This is the second attempt to fix this issue, my first patch can be
seen here:
In the first patch I was to checking in normal_stop, immediately after
the call to update_thread_list, to see if the current thread was now
marked as exited. However CI testing showed an issue with this
approach; I was already checking for many different TARGET_WAITKIND_*
kinds where the "is the current thread exited" question didn't make
sense, and it turns out that the list of kinds in my first attempt was
already insufficient.
Rather than trying to just adding to the list, in this revised patch
I'm proposing to move the "is this thread exited" check inside the
block which handles signal stop events.
Right now, the only part of normal_stop which I know relies on the
current thread not being exited is the call to notify_signal_received,
so before calling notify_signal_received I check to see if the current
thread is now exited. If it is then I print a warning to indicate
that the thread has unexpectedly exited and that the current
command (continue/step/etc) has been cancelled, I then change the
current event type to TARGET_WAITKIND_SPURIOUS.
GDB's output now looks like this in all-stop mode:
The non-stop output is identical, except we don't switch thread (stop
events never trigger a thread switch in non-stop mode).
The include test makes use of the gdbreplay framework, and tests in
all-stop and non-stop modes. I would like to do more extensive
testing of GDB's state after the receiving the unexpected thread list,
but due to using gdbreplay for testing, this is quite hard. Many
commands, especially those looking at thread state, are likely to
trigger additional packets being sent to the remote, which causes
gdbreplay to bail out as the new packet doesn't match the original
recorded state. However, I really don't think it is a good idea to
change gdbserver in order to "fake" this error case, so for now, using
gdbreplay is the best idea I have.
Andrew Burgess [Fri, 1 Aug 2025 11:26:41 +0000 (12:26 +0100)]
gdbserver: better handling for missing argument values
By passing ':' within the optstring to getopt_long, the getopt_long
call will now return ':' for missing value errors and '?' for unknown
argument errors, rather than returning '?' for all error types.
We can now print a different error message for missing argument
values. For example:
$ gdbserver --debug-file :54321 /tmp/hello
Missing argument value for: --debug-file
Andrew Burgess [Fri, 1 Aug 2025 11:22:38 +0000 (12:22 +0100)]
gdbserver: allow gnu style arguments to gdbserver
Now that we use getopt_long for argument processing in gdbserver, it
is relatively easy to support GNU style arguments, that is, arguments
passed without an '=' between the argument and the value.
As support for GNU style arguments is the default from getopt_long,
the first part of this commit is to remove the code which deliberately
disables the GNU argument support.
With that done, we now need to consider optional arguments. In this
case, getopt_long doesn't automatically grab the next word from ARGV
to be the argument value, so I've added some code to do this.
I've also tried to make this code a little smart. As the first
argument passed to gdbserver that doesn't have a '--' at the start is
the PORT number, the new code block I've added tries to spot if the
argument value might be the port number. If it is, then we don't
allow the port number to become the argument value, and instead, we
pretend the argument value is missing. This seems to give better
error messages.
There are going to be UI changes in how gdbserver handles incorrect
arguments after this commit. However, the behaviour for valid
command lines should be unchanged.
Support the fs_base and gs_base registers on i386.
So the SSP overlap is new, but the fs/gs base overlap has existed for
years, so why did it not cause any problems?
I think the explanation is that on i386, the fs/gs base are only used
for FreeBSD, all the calls to i386_target_description that pass true
for the segments argument are from fbsd files. As a result, its fine
if there's numbering overlap between these i386 registers and some
Linux specific i386 registers.
OK, but what about the new SSP (shadow stack pointer) register?
I think in this case we would see problems, if the shadow stack was
supported for i386. Here's what the docs say:
The ‘org.gnu.gdb.i386.pl3_ssp’ feature is optional. It should
describe the user mode register ‘pl3_ssp’ which has 64 bits on amd64, 32
bits on amd64 with 32-bit pointer size (X32) and 32 bits on i386.
Following the restriction of the Linux kernel, only GDB for amd64
targets makes use of this feature for now.
And indeed, if we look for callers of x86_supply_ssp, which supplies
the shadow stack pointer register, this is only called from amd64
specific code, either the native register fetching, or the core file
loading. There's no calls from i386 code.
And so, again, we have register number overlap, but we avoid any
issues by not making use of these registers for i386 linux.
Here's my question: Is this super clever design aimed at saving 12
bytes (3 * 4-byte registers) of space in the i386 regcache? Or is
this an accident where we happen to have gotten lucky?
If it's the first, then I really think there should be some comments
explaining what's going on.
If it's the second, then maybe we should fix this before it trips us
up?
This commit takes the second approach by doing the following:
1. In i386-tdep.h move all the *_NUM_REGS constants to be members of
'enum i386_regnum'. The I386_NUM_REGS value can be automatically
calculated based off the (current) last enum entry, and the
other *_NUM_REGS constants are calculated just as they previously
were, but are moved to keep them all together.
2. In i386-linux-tdep.h, I386_LINUX_ORIG_EAX_REGNUM and
I386_LINUX_NUM_REGS are moved into a new enum i386_linux_regnum,
the name of which is inspired by i386_regnum with the addition
of the linux tag. The first entry in this new enum starts from
I386_NUM_REGS rather than I386_PKRU_REGNUM. The
I386_LINUX_NUM_REGS will be calculated automatically by the
compiler.
3. In amd64-linux-nat.c, I extend amd64_linux_gregset32_reg_offset
so that it now has entries for the 3 registers that are no longer
aliasing, this stops an assert from the end of the file
triggering:
4. Given (3) I wondered why there was no assert being triggered from
the i386 code as i386_linux_gregset_reg_offset, in i386-linux-tdep.c
is clearly also wrong now.
So, In i386-linux-tdep.c I've added a new assertion at the end of
the file.
And then I've fixed i386_linux_gregset_reg_offset by adding the 3
new registers.
With these changes made I believe that the register number for the
$orig_eax register on i386 GNU/Linux targets should no longer be
aliasing with the SSP register.
For the reasons given above, I don't think this fixes any actual bugs,
it's more just a, lets not have unnecessary, and undocumented,
register number aliasing.
This change is visible using 'maint print registers', check out the
register number of $orig_eax before and after, it should now be +3
from where it was (changed from 72 to 75).
I did worry briefly about gdbservers that might not support XML target
descriptions and instead rely on a fixed GDB register numbering.
Though, if I'm honest, I have very little sympathy for such gdbservers
these days. Still, they could, potentially be tripped up by this
change. However, this is not the first time in recent years that the
value of I386_LINUX_ORIG_EAX_REGNUM has changed. This commit also
adjusted the register number:
Add support for Intel PKRU register to GDB and GDBserver.
And I'm not aware of any bug reports that came from this, we certainly
didn't feel the need to adjust the register number back again. So I'm
guessing that this renumbering will also go without issue.
Other than that, there should be no user visible changes after this
commit.
Reviewed-By: Christina Schimpe <christina.schimpe@intel.com>
Pedro Alves [Tue, 23 Sep 2025 10:40:27 +0000 (11:40 +0100)]
Adjust gdb.base/memops-watchpoint.exp for native Windows
On native Windows, I see:
continue
Continuing.
Thread 1 hit Hardware watchpoint 2: -location a[28]
Old value = 104 'h'
New value = 0 '\000'
0x00007ffe640a9953 in msvcrt!memmove () from C:\Windows\System32\msvcrt.dll
(gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
... two more of the same ...
This fails for a few reasons:
1) thread_prefix_re
The thread_prefix_re regexp doesn't handle the case of a thread with
no name:
set thread_prefix_re "(?:Thread $::decimal \[^\r\n\]* hit )?"
^ ^
Note how it expects two spaces between the thread number and the
"hit" word.
Fix it by dropping one of the spaces in the regexp.
2) libc vs msvcrt.dll
This:
-re ".*${function_re}.* \\(\\) from .*libc\[^\r\n\]+\r\n" {
is expecting that the function exists in libc, which is not the case
on Windows.
Fix it by not expecting any particular library name.
3) endline consumed when it shouldn't
All these patterns:
-re ".*${function_re}.* \\(\\) at .*:$::decimal\r\n" {
-re ".*${function_re}.* \\(\\) from .*libc\[^\r\n\]+\r\n" {
-re "in \\?\\? \\(\\) from .*libc\[^\r\n\]+\r\n" {
... consume the \r\n, and then do exp_continue, expecting that
eventually the:
-re -wrap "" {
... pattern matches. However, if the \r\n is already consumed, then
-wrap doesn't work, because that expects "\r\n$gdb_prompt ".
This wasn't noticed on Linux because there GDB prints at least one
more line before the prompt:
Old value = 104 'h'
New value = 0 '\000'
__memset_avx2_unaligned_erms () at ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S:171
warning: 171 ../sysdeps/x86_64/multiarch/memset-vec-unaligned-erms.S: No such file or directory
(gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
...
Old value = 100 'd'
New value = 114 'r'
__memcpy_avx_unaligned_erms () at ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:272
272 in ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S
(gdb) PASS: gdb.base/memops-watchpoint.exp: continue until memmove watchpoint hits
...
Fix it by expecting but not consuming the endlines.
4) msvcrt.dll implements memset with memmove
Note how we are expecting a memset hit, but we get a memmove:
0x00007ffe640a9953 in msvcrt!memmove () from C:\Windows\System32\msvcrt.dll
(gdb) FAIL: gdb.base/memops-watchpoint.exp: continue until memset watchpoint hits
We already handle memcpy implemented with memmove and vice versa.
Fix it by handling memset implemented with memmove in the same way.
With all these fixed, the test now passes cleanly on native Windows.
It still passes cleanly on GNU/Linux.
projects / thirdparty / binutils-gdb.git / log
