| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
This updates the copyright headers to include 2025. I did this by
running gdb/copyright.py and then manually modifying a few files as
noted by the script.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
This commit is the result of the following actions:
- Running gdb/copyright.py to update all of the copyright headers to
include 2024,
- Manually updating a few files the copyright.py script told me to
update, these files had copyright headers embedded within the
file,
- Regenerating gdbsupport/Makefile.in to refresh it's copyright
date,
- Using grep to find other files that still mentioned 2023. If
these files were updated last year from 2022 to 2023 then I've
updated them this year to 2024.
I'm sure I've probably missed some dates. Feel free to fix them up as
you spot them.
|
|
This commit is the result of running the gdb/copyright.py script,
which automated the update of the copyright year range for all
source files managed by the GDB project to be updated to include
year 2023.
|
|
This commit brings all the changes made by running gdb/copyright.py
as per GDB's Start of New Year Procedure.
For the avoidance of doubt, all changes in this commits were
performed by the script.
|
|
As reported in PR gdb/28077, we hit an internal error when using
-exec-interrupt with --thread-group:
info threads
&"info threads\n"
~" Id Target Id Frame \n"
~"* 1 process 403312 \"loop\" (running)\n"
^done
(gdb)
-exec-interrupt --thread-group i1
~"/home/simark/src/binutils-gdb/gdb/target.c:3768: internal-error: void target_stop(ptid_t): Assertion `!proc_target->commit_resumed_state' failed.\nA problem internal to GDB has been detected,\nfurther debugging may prove unreliable.\nQuit this debugging session? (y or n) "
This is because this code path never disables commit-resumed (a
requirement for calling target_stop, as documented in
process_stratum_target::»commit_resumed_state) before calling
target_stop.
The other 3 code paths in mi_cmd_exec_interrupt use interrupt_target_1,
which does it. But the --thread-group code path uses its own thing
which doesn't do it. Fix this by adding a scoped_disable_commit_resumed
in this code path.
Calling -exec-interrupt with --thread-group is apparently not tested at
the moment (which is why this bug could creep in). Add a new test for
that. The test runs two inferiors and tries to interrupt them with
"-exec-interrupt --thread-group X".
This will need to be merged in the gdb-11-branch, so here are ChangeLog
entries:
gdb/ChangeLog:
* mi/mi-main.c (mi_cmd_exec_interrupt): Use
scoped_disable_commit_resumed in the --thread-group case.
gdb/testsuite/ChangeLog:
* gdb.mi/interrupt-thread-group.c: New.
* gdb.mi/interrupt-thread-group.exp: New.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28077
Change-Id: I615efefcbcaf2c15d47caf5e4b9d82854b2a2fcb
|
