Chris Packham [Wed, 30 Apr 2025 04:49:44 +0000 (16:49 +1200)]
readline/tcap.h: Update definitions for C23
C23 changes how function definitions like int `int tputs ()` are
interpreted. In older standards this meant that the function arguments
are unknown. In C23 this is interpreted as `int tputs (void)` so now
when we compile with GCC15 (which defaults to -std=gnu23) we get an
error such as
readline/display.c:2839:17: error: too many arguments to function 'tputs'; expected 0, have 3
Add the function arguments for tgetent(), tgetflag(), tgetnum(),
tgetstr(), tputs() and tgoto().
Signed-off-by: Chris Packham <judge.packham@gmail.com> Approved-By: Tom Tromey <tom@tromey.com>
(cherry picked from commit 5c87b330e910f8be1443c881fd16a70e685f1f2f)
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33071
Keith Seitz [Mon, 7 Apr 2025 15:40:56 +0000 (08:40 -0700)]
gstack: [downstream regression] Output file names and line numbers
With commit fb2ded33c1e519659743047ed7817166545b6d91, I added
Fedora's gstack script to gdb. Some issues have arisen since
then, and this patch addresses those issues:
. As Sam James recently noted[1], PKGVERSION and VERSION
need to be quoted.
. A Fedora user reported the misuse of --readnever, which
causes gstack to omit filename and line number information in the
backtrace[Red Hat BZ 2354997].
Luis Machado [Mon, 7 Apr 2025 08:24:57 +0000 (09:24 +0100)]
Fix build failure for gdbserver's raw_compare self test
Commit 5c89e5539aef2992a2417be55307c9071ffbe89c addressed a SVE/SME gdbserver
crash on gdbserver and added a gdbserver-side self test for a register cache
raw_compare function.
For the GDB 16 branch though, gdbserver's regcache doesn't yet have a
constructor taking a target description, so we need to explicitly initialize
the register cache before the self test can take place.
Also, the self tests are only built if we explicitly pass --enable-unit-tests
to configure. This build error should not manifest on a default build that
doesn't enable self tests.
Luis Machado [Fri, 28 Feb 2025 09:36:42 +0000 (09:36 +0000)]
Fix gdbserver crashes on SVE/SME-enabled systems
Commit 51e6b8cfd649013ae16a3d00f1451b2531ba6bc9 fixed a
regression for SVE/SME registers on gdb's side by using a <= comparison for
regcache's raw_compare assertion check. We seem to have failed to do the same
for gdbserver's raw_compare counterpart.
With the code as it is, I'm seeing a lot of crashes for gdbserver on a machine
with SVE enabled. For instance, with the following invocation:
make check-gdb RUNTESTFLAGS="--target_board=native-gdbserver" TESTS=gdb.base/break.exp
Running /work/builds/binutils-gdb/gdb/testsuite/../../../../repos/binutils-gdb/gdb/testsuite/gdb.base/break.exp ...
FAIL: gdb.base/break.exp: test_break: run until function breakpoint
FAIL: gdb.base/break.exp: test_break: run until breakpoint set at a line number (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(6) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(5) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(4) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(3) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(2) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:function(1) breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until quoted breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: run until file:linenum breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: breakpoint offset +1
FAIL: gdb.base/break.exp: test_break: step onto breakpoint (the program is no longer running)
FAIL: gdb.base/break.exp: test_break: setting breakpoint at }
FAIL: gdb.base/break.exp: test_break: continue to breakpoint at } (the program is no longer running)
FAIL: gdb.base/break.exp: test_no_break_on_catchpoint: runto: run to main
FAIL: gdb.base/break.exp: test_break_nonexistent_line: runto: run to main
FAIL: gdb.base/break.exp: test_break_default: runto: run to main
FAIL: gdb.base/break.exp: test_break_silent_and_more: runto: run to main
FAIL: gdb.base/break.exp: test_break_line_convenience_var: runto: run to main
FAIL: gdb.base/break.exp: test_break_user_call: runto: run to main
FAIL: gdb.base/break.exp: test_finish_arguments: runto: run to main
FAIL: gdb.base/break.exp: test_next_with_recursion: kill program
FAIL: gdb.base/break.exp: test_next_with_recursion: run to factorial(6)
FAIL: gdb.base/break.exp: test_next_with_recursion: continue to factorial(5) (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5)
FAIL: gdb.base/break.exp: test_next_with_recursion: next to recursive call (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: next over recursive call (the program is no longer running)
FAIL: gdb.base/break.exp: test_next_with_recursion: backtrace from factorial(5.1)
FAIL: gdb.base/break.exp: test_next_with_recursion: continue until exit at recursive next test (the program is no longer running)
FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until function breakpoint, optimized file
FAIL: gdb.base/break.exp: test_break_optimized_prologue: run until breakpoint set at small function, optimized file (the program is no longer running)
FAIL: gdb.base/break.exp: test_rbreak_shlib: rbreak junk
Adjusting the regcache raw_compare assertion check to use <= fixes
the problem on aarch64-linux on a SVE-capable system.
This patch also adds a simple selftest to gdbserver that validates this
particular case by simulating a raw_compare operation.
This commit allows the escape sequences \x1b[39m and \x1b[49m, which
select the default foreground and background colours respectively, to
work correctly.
This fix is just a small part of the above commit. Only these two
changes are required to fix this bug. As we are currently preparing
for a 16.3 release, I don't think we should be pulling in the whole of
the above commit.
Craig Blackmore [Thu, 13 Feb 2025 15:53:34 +0000 (15:53 +0000)]
gdb: Fix assertion failure when inline frame #0 is duplicated
Modifying inline-frame-cycle-unwind.exp to use `bt -no-filters` produces
the following incorrect backtrace:
#0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
#1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
#2 0x000055555555517f in inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:50
#3 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
The expected output, which we get with `bt`, is:
#0 inline_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:49
#1 normal_func () at .../gdb/gdb/testsuite/gdb.base/inline-frame-cycle-unwind.c:32
Backtrace stopped: previous frame identical to this frame (corrupt stack?)
(gdb) PASS: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1
The cycle checking in `get_prev_frame_maybe_check_cycle` relies on newer
frame ids having already been computed and stashed. Unlike other
frames, frame #0's id does not get computed immediately.
The test passes with `bt` because when applying python frame filters,
the call to `bootstrap_python_frame_filters` happens to compute the id
of frame #0. When `get_prev_frame_maybe_check_cycle` later tries to
stash frame #2's id, the cycle is detected.
The test fails with `bt -no-filters` because frame #0's id has not been
stashed by the time `get_prev_frame_maybe_check_cycle` tries to stash
frame #2's id which succeeds and the cycle is only detected later when
trying to stash frame #4's id. Doing `stepi` after the incorrect
backtrace would then trigger an assertion failure when trying to stash
frame #0's id because it is a duplicate of #2's already stashed id.
In `get_prev_frame_always_1`, if this_frame is inline frame 0, then
compute and stash its frame id before returning the previous frame.
This ensures that the id of inline frame 0 has been stashed before
`get_prev_frame_maybe_check_cycle` is called on older frames.
The test case has been updated to run both `bt` and `bt -no-filters`.
Co-authored-by: Andrew Burgess <aburgess@redhat.com>
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32757
projects / thirdparty / binutils-gdb.git / log
