| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Test behaviour of watchpoints triggered by MOPS instructions. This test
is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS
instructions rather than whatever instructions are used in the libc's
implementation of memset/memcpy/memmove.
There's a separate watched variable for each set of instructions so that
the testcase can test whether GDB correctly identified the watchpoint
that triggered in each case.
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
There are two kinds of MOPS instructions: set instructions and copy
instructions. Within each group there are variants with minor
differences in how they read or write to memory — e.g., non-temporal
read and/or write, unprivileged read and/or write and permutations of
those — but they work in the same way in terms of the registers and
regions of memory that they modify.
The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS
instructions are recorded and correctly reversed. Not all variants of the
copy and set instructions are tested, since there are many and the record
and replay target processes them in the same way.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
The AArch64 MOPS (Memory Operation) instructions provide a standardised
instruction sequence to perform a memset, memcpy or memmove. A sequence is
always composed of three instructions: a prologue instruction, a main
instruction and an epilogue instruction. As an illustration, here are the
implementations of these memory operations in glibc 2.39:
(gdb) disassemble/r
Dump of assembler code for function __memset_mops:
=> 0x0000fffff7e8d780 <+0>: d503201f nop
0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1
0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1
0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1
0x0000fffff7e8d794 <+20>: d65f03c0 ret
End of assembler dump.
(gdb) disassemble/r
Dump of assembler code for function __memcpy_mops:
=> 0x0000fffff7e8c580 <+0>: d503201f nop
0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2!
0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2!
0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2!
0x0000fffff7e8c594 <+20>: d65f03c0 ret
End of assembler dump.
(gdb) disassemble/r
Dump of assembler code for function __memmove_mops:
=> 0x0000fffff7e8d180 <+0>: d503201f nop
0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0
0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2!
0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2!
0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2!
0x0000fffff7e8d194 <+20>: d65f03c0 ret
End of assembler dump.
The Arm Architecture Reference Manual says that "the prologue, main, and
epilogue instructions are expected to be run in succession and to appear
consecutively in memory". Therefore this patch disables displaced stepping
on them.
The testcase verifies that MOPS sequences are correctly single-stepped.
PR tdep/31666
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666
Approved-By: Luis Machado <luis.machado@arm.com>
Tested-By: Luis Machado <luis.machado@arm.com>
|
|
In arm-linux-tdep.c, ARM_LINUX_JB_PC_EABI is defined as 9, but it's been 1
since glibc 2.20.
See glibc commit 80a56cc3ee ("ARM: Add SystemTap probes to longjmp and
setjmp.").
Update it, allowing us to run into the gdb/26967 kfail.
Tested on arm-linux.
Approved-By: Luis Machado <luis.machado@arm.com>
PR arm/tdep
Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31089
|
|
When running test-case gdb.fortran/array-bounds.exp on arm-linux, we run into:
...
(gdb) print &foo^M
$1 = (PTR TO -> ( real(kind=4) (0:1) )) 0xfffef008^M
(gdb) FAIL: gdb.fortran/array-bounds.exp: print &foo
print &bar^M
$2 = (PTR TO -> ( real(kind=4) (-1:0) )) 0xfffef010^M
(gdb) FAIL: gdb.fortran/array-bounds.exp: print &bar
...
This is due to gcc PR debug/54934.
The test-case contains a kfail for this, which is only activated for
x86_64/i386.
Fix this by enabling the kfail for all ilp32 targets.
Also:
- change the kfail into an xfail, because gdb is not at fault here, and
- limit the xfail to the gfortran compiler.
Tested on arm-linux.
|
|
In commit:
commit 824083f34c222aa7419e2ea58e82d6f230d5f531
Date: Fri Apr 12 17:47:20 2024 +0100
gdb/doc: use silent-rules.mk in the Makefile
I rewrote the rules for building the man pages. While doing this I
accidentally switched from using MAN2POD5 to MAN2POD1 for generating
the file gdbinit.5.
Restore use of MAN2POD5 where appropriate.
|
|
Previously a "stepOut" request when in the outermost frame would result
in a sucessful response even though gdb internally would reject the
associated "finish" request, which means no stoppedEvent would ever be
sent back to the client. Thus the client would believe the inferior was
still running and as a consequence reject subsequent "next" and "stepIn"
requests from the user.
The solution is to execute the underlying finish command as a background
command, i.e. `finish &`. If we're in the outermost frame an exception
will be raised immediately, which we can now capture and report back to
the client as success=False so then the absence of a `stopped` event is
no longer a problem.
We also make use of the `defer_stop_event` option to prevent a stop
event from reaching the client until the response has been sent.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This allows a request to specify that any gdb exception raised in
exec_and_log within the gdb thread to be propagated back to the DAP
thread (using the Canceller object as the orchestrator).
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The existing `send_event_later()` method allows commands processed on
the DAP thread to queue an event for execution until after the response
has been sent to the client.
We now introduce a corresponding method for use by the gdb thread. This
method `send_event_maybe_later()` will queue the event just like
`send_event_later()`, but only if it has been configured to do so by a
new @request option `defer_stop_events`. As the name implies the
functionality is currently only used for handling stop events.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I noticed that the value returned by rust_llvm_version had a trailing
carriage return. I don't think this is causing any problems right
now, but looking at the code I don't think this was the desired
behaviour.
The current code runs 'rustc --version --verbose', splits the output
at each '\n' and then loops over every line looking for the line that
contains the LLVM version.
There are two problems here. First, at the end of each captured line
we have '\r\n', so when we split the lines on '\n', each of the lines
will still end with a '\r' character.
Second, though we loop over the lines, when we try to compare the line
contents we actually compare the unsplit full output. Luckily this
still finds the match, but this renders the loop over lines redundant.
This commit makes two fixes:
1. I use regsub to convert all '\r\n' sequences to '\n'; now when we
split on '\n' the lines will not end in '\r'.
2. Within the loop over lines block I now check the line contents
rather than the unsplit full output; now we capture a value
without a trailing '\r'.
There's only one test (gdb.rust/simple.exp) that uses
rust_llvm_version, and it doesn't care if there's a trailing '\r' or
not, so this change should make no difference there.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
I spotted a few more places where we could apply filename styling in
remote.c and target.c. Other than the styling, there should be no
user visible changes after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
A co-worker requested that the DAP code emit a scope for global
variables. It's not really practical to do this for all globals, but
it seemed reasonable to do this for globals coming from the frame's
compilation unit. For Ada in particular, this is convenient as it
exposes package-scoped variables.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
|
|
This changes the DAP disassemble code to use the new Block hashing,
storing the already-visited blocks in a set rather than a list.
|
|
In subsequent patches, it's handy if gdb.Block is hashable, so it can
be stored in a set or a dictionary. However, doing this in a
straightforward way is not really possible, because a block isn't
truly immutable -- it can be invalidated. And, while this isn't a
real problem for my use case (in DAP the maps are only used during a
single stop), it seemed error-prone.
This patch instead takes the approach of using the gdb.Block's own
object identity to allow hashing. This seems fine because the
contents don't affect the hashing. In order for this to work, though,
the blocks have to be memoized -- two requests for the same block must
return the same object.
This also allows (actually, requires) the simplification of the
rich-compare method for blocks.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
I noticed a FIXME comment in the DAP code about adding a "source"
field to a scope. This is easy to implement; I don't know why I
didn't do this originally.
|
|
After the previous bcache change, a couple of casts in objfiles.h are
now redundant.
|
|
The bcache uses memcpy to make copies of the data passed to it. In
C++, this is only safe for trivially-copyable types.
This patch changes bcache to require this property, and slightly
changes the API to make it easier to use when copying a single object.
It also makes the new 'insert' template methods return the correct
type.
|
|
This patch changes some spots in psymtab.[ch] to use 'const'. This is
just preparation for a subsequent patch. Note that psymbols are
conceptually const, and since they were changed to be
objfile-indepdendent, they are truly never modified -- which is what
makes this patch reasonably short.
|
|
std::uncaught_exceptions is a C++17 feature, so I think we can remove
this conditional code from inferior.h.
|
|
|
|
Add tests for looking up debug information within the sysroot via both
build-id and gnu_debuglink.
I wanted to ensure that the gnu_debuglink test couldn't make use of
build-ids, so I added the 'no-build-id' flag to gdb_compile.
As these tests rely on setting the sysroot, if I'm running a
dynamically linked executable, GDB will try to find all shared
libraries within the sysroot. This would mean I'd have to figure out
and copy all shared libraries the executable uses, certainly possible,
but a bit of a pain.
So instead, I've just compiled the test executable as a static binary.
Now there are no shared library dependencies.
I can now split the debug information out from the test binary, and
place it within the sysroot. When GDB is started and the executable
loaded, we can check that GDB is finding the debug information within
the sysroot.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
While writing a test I realised that the default behaviour of
gdb_gnu_strip_debug doesn't match its comment.
The comment says that the function takes a FILENAME, and splits the
file into FILENAME.stripped and FILENAME.debug, leaving FILENAME
unchanged. The comment says that a .gnu_debuglink will be added to
FILENAME.stripped.
However, this is not true, FILENAME.stripped is created, with no debug
information. FILENAME.debug is created containing the debug
information.
But, when adding the .gnu_debuglink we take FILENAME.stripped as the
input, and then overwrite FILENAME with the output. As a result,
FILENAME.stripped does not include a .gnu_debuglink, while FILENAME
contains the .gnu_debuglink and no debug information!
The users of gdb_gnu_strip_debug can be split into two groups, those
who are using the .gnu_debuglink, these tests are all written assuming
that FILENAME is updated.
Then there are some tests that only rely on gdb_gnu_strip_debug's
ability to split out the debug information, these tests are then going
to do a lookup based on the build-id, these tests don't require the
.gnu_debuglink. These tests use the FILENAME.stripped output file.
This all seems too confused to me.
As most uses of gdb_gnu_strip_debug assume that FILENAME is updated, I
propose that we just make that the actual, advertised behaviour of
this proc.
So now, gdb_gnu_strip_debug will take FILENAME, and will split the
debug information out into FILENAME.debug. The debug information will
then be stripped from FILENAME, and by default a .gnu_debuglink will
be added to FILENAME pointing to FILENAME.debug.
I've updated the two tests that actually relied on FILENAME.stripped
to instead just use FILENAME.
One of the tests was doing a build-id based lookup, but was still
allowing the .gnu_debuglink to be added to FILENAME, I've updated this
test to pass the no-debuglink flag to gdb_gnu_strip_debug, which stops
the .gnu_debuglink from being added.
All of the tests that call gdb_gnu_strip_debug still pass for me.
Acked-By: Tom de Vries <tdevries@suse.de>
|
|
When building in a fresh directory we'll see some output like this:
/bin/sh ../../src/gdb/../mkinstalldirs arch/.deps
mkdir -p -- arch/.deps
/bin/sh ../../src/gdb/../mkinstalldirs cli/.deps
mkdir -p -- cli/.deps
/bin/sh ../../src/gdb/../mkinstalldirs dwarf2/.deps
mkdir -p -- dwarf2/.deps
... etc ...
this commit uses silent-rules.mk to silence this output, now we'll
see:
GEN arch/.deps
GEN cli/.deps
GEN dwarf2/.deps
... etc ...
The recipe that currently generates these directories uses
mkinstalldirs, as I mention in commit 032e5e0c0c08977, mkinstalldirs
is deprecated and 'install-sh -d' should be used instead. This
silences the 'mkdir -p -- ...' part of the output.
There should be no change in what is actually built after this commit.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
This removes a call to can_box from
tui_source_window_base::show_source_content. can_box will always
return true here.
Approved-By: Andrew Burgess <aburgess@redhat.com>
|
|
I noticed one spot where deprecate_cmd is called with a second
argument that is not a command name. This patch fixes the problem.
Regression tested on x86-64 Fedora 38.
|
|
If you try to use the overloaded subscript operator of a class
in python, it fails like this:
(gdb) py print(gdb.parse_and_eval('b')[5])
Traceback (most recent call last):
File "<string>", line 1, in <module>
gdb.error: Cannot subscript requested type.
Error while executing Python code.
This simply checks if such an operator exists, and calls it
instead, making this possible:
(gdb) py print(gdb.parse_and_eval('b')[5])
102 'f'
Approved-By: Tom Tromey <tom@tromey.com>
|
|
As mentioned in PR13326, currently when you try to call a
convenience function with python, you get this error:
(gdb) py print(gdb.convenience_variable("_isvoid")(3))
Traceback (most recent call last):
File "<string>", line 1, in <module>
RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD).
Error while executing Python code.
So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as
well, making this possible:
(gdb) py print(gdb.convenience_variable("_isvoid")(3))
0
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326
Approved-By: Tom Tromey <tom@tromey.com>
|
|
When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run
into:
...
tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable
^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout)
...
The test-case does "Term::resize 24 80 0" while having the settings of an
earlier "Term::resize 40 90", so both dimensions change.
When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc:
- calls stty to change one dimension,
- waits for the message (enabled by "maint set tui-resize-message on")
confirming the resize has happened,
- calls stty to change the other dimension, and again
- waits for the message confirming the resize has happened.
Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the
message is not printed, so stty is called twice, and afterwards we check for
the results of the two resizes, which is the test that is failing.
The problem is that not waiting for a response after each stty call opens up
the possibility of the responses being merged.
Fix this by calling Term::resize twice, changing one dimension at a time, and
waiting for a single prompt redisplay after each one.
Tested on x86_64-linux.
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
PR testsuite/31822
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822
|
|
I noticed a typo in a comment in tui-data.h.
|
|
Printing the value of 'errno' from GDB is sometimes problematic. The
situation has improved in recent years, though there are still
scenarios for which "print errno" doesn't work.
The test, gdb.base/errno.exp, introduced by this commit, tests whether
or not GDB can print errno using a binary compiled in the following
different ways:
- default: no switches aside from -g (and whatever else is added by the
testing framework)
- macros: macro info is included in the debuginfo; this is enabled by
using -g3 when using gcc or clang
- static: statically linked binary
- static-macros: statically linked binary w/ macro definitions included
in debuginfo
- pthreads: libpthread linked binary
- pthreads-macros: libpthread linked binary w/ macro definitions included
in debuginfo
- pthreads-static: Statically linked against libpthread
- pthreads-static-macros: Statically linked against libpthread w/ macro
definitions
For each of these, the test also creates a corefile, then loads the
corefile and attempts to print errno again.
Additionally, the test checks that a "masking" errno declared as a
local variable will print correctly.
On Linux, if the machine is missing glibc debuginfo (or you have
debuginfod disabled), it's likely you'll see:
(gdb) print errno
'errno' has unknown type; cast it to its declared type
But if you add a cast, the value of errno is often available:
(gdb) print (int) errno
$1 = 42
The test detects this situation along with several others and does
'setup_xfail' for tests that will almost certainly fail. It could be
argued that some of these ought to be KFAILs due to deficiencies in
GDB, but I'm not entirely certain which, if any, are fixable yet.
On Fedora 39, without glibc debuginfo, there are no failures, but
I do see the following XFAILS:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
On Fedora 39, with glibc debug info, but without libc.a (for static
linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED
tests.
So, even when testing in less than ideal conditions, either due to lack
of glibc debuginfo or lack of a libc to link against to make a static
binary, there are no failures.
With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40,
Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs:
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
On FreeBSD 13.1, the total number of XFAILs are fewer, and could be
even better still if it had debug info for glibc:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
Starting with glibc-2.34, most of the pthreads library has been
incorporated into libc, so finding thread-local variables using
libthread_db is possible for several scenarios in which it previously
wasn't. But, prior to this, accessing errno for the default scenario
was a problem. This is borne out by running this new test on Fedora
34, which uses glibc-2.33:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: print errno
XFAIL: gdb.base/errno.exp: static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
In the v3 version of this test, Tom de Vries tested on openSUSE Leap
15.5 and found a number of cases which showed a FAIL instead of an
XFAIL. The v4 version of this test fixed those problems. On Leap
15.5, which uses glibc-2.31, with glibc debug info, I now see:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
On Leap 15.5, with glibc debuginfo missing, the results are a little
worse:
XFAIL: gdb.base/errno.exp: default: print errno
XFAIL: gdb.base/errno.exp: default: print (int) errno
XFAIL: gdb.base/errno.exp: default: check errno value from corefile
XFAIL: gdb.base/errno.exp: macros: print errno
XFAIL: gdb.base/errno.exp: macros: print (int) errno
XFAIL: gdb.base/errno.exp: macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: static: print errno
XFAIL: gdb.base/errno.exp: static: print (int) errno
XFAIL: gdb.base/errno.exp: static: check errno value from corefile
XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads: print errno
XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-macros: print errno
XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static: print errno
XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno
XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile
XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile
The v5 version of this test fixed failures when testing with
check-read1. (Thanks to Linaro CI for finding these.) I revised the
regular expressions being used so that the failures were eliminated,
but the results mentioned above have not changed.
The v6 version of this test fixes some nits pointed out by both Tom
de Vries and Pedro Alves. One of Pedro's suggestions was to rename the
test from check-errno.exp to errno.exp, so in v5, the name has
changed. Tom also noticed that there were failures when using
--target_board=native-extended-gdbserver. For v6, I've tested on 10
different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o
static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o
glibc debuginfo, and Fedora 34) using "make check" and "make check-read1"
using target boards "unix", "native-extended-gdbserver", and
"native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for
a total of 12 distinct test runs on each machine. I've also tested the
native-only cases on FreeBSD. (Attempting to test against gdbserver
on FreeBSD resulted in hangs while running the test suite.)
The v7 version of this test simplifies the REs used in the uses of
gdb_test_multiple by adding -wrap and removing parts of the REs which
match the GDB prompt. In cases where there was a leading '.*', those
were removed too. Thanks to Pedro for explaining how to use -wrap.
So, bottom line, this test does not introduce any new failures on the
platforms on which I've tested, but the XFAILs are certainly unfortunate.
Some aren't fixable - e.g. when attempting to make a function call while
debugging a core file - but I think that some of them are. I'm using
this new test case as a starting point for investigating problems with
printing errno.
Co-Authored-By: Jan Kratochvil
Approved-By: Tom de Vries <tdevries@suse.de>
|
|
dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader,
so this field can be moved to mapped_gdb_index instead. Then,
cooked_index_functions::find_per_cu can be removed in favor of a
method on the index object.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
These structs are not referenced anywhere anymore and seemed to have been
missed at some point when their usage was removed.
Co-authored-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
Approved-By: Tom Tromey <tom@tromey.com>
|
|
org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the
docs yet. Fix that.
In addition the documentation describes xmm registers with an `h`
(e.g. xmm16h). I am assuming that we follow the register xml files here,
which don't have the h suffix. So this removes that as well.
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
Remove some includes reported as unused by clangd. Add some includes in
other files that were previously relying on the transitive include.
Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e
|
|
Remove some includes reported as unused by clangd.
Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6
|
|
Remove some includes reported as unused by clangd.
Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d
|
|
While preparing the new release it was discovered that commit:
commit 824083f34c222aa7419e2ea58e82d6f230d5f531
Date: Fri Apr 12 17:47:20 2024 +0100
gdb/doc: use silent-rules.mk in the Makefile
was causing problems. Given a release tar file, an attempt to build
and install GDB would give an error like this:
[...]
TEXI2POD gdb.pod
cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, <GEN0> line 16.
make[5]: *** [Makefile:663: gdb.pod] Error 2
The problem here is how the man pages are built, and how they are
distributed within a release.
Within the development (git) tree, the man page files are not part of
the source tree, these files are built as needed. Within a release
tar file though, the man pages are included. The idea being that a
user can build and install GDB, including getting the man pages,
without having to install the tools needed to generate the man pages.
The man pages are generated in a two step process. First the .texi
file is processed with texi2pod to create a .pod file, then this .pod
file is processed to create the .1 or .5 man file.
Prior to the above commit these two steps were combined into a single
recipe, this meant that when a user performed a build/install from a
release tree all of the dependencies, as well as the final result,
were all present in the source tree, and so nothing needed to be
rebuilt.
However, the above commit split the two steps apart. Now we had a
separate rule for building the .pod files, and the .1/.5 man page
files depended on the relevant .pod file.
As the .pod files are not shipped in a GDB release, this meant that
one of the dependencies of the man page files was now missing. As a
result if a user tried to install from a release tree a rebuild of the
.pod files would be attempted, and if that succeeded then building the
man pages would follow that.
Unfortunately, building the .pod files would fail as the GDBvn.texi
file, though present in the source tree, was not present in the build
tree, which is where it is needed for the .pod file generation to
work.
To fix this, I propose merging the .pod creation and the .1/.5 man
page creation back into a single recipe. Having these two steps split
is probably the "cleaner" solution, but makes it harder for us to
achieve our goal of shipping the prebuilt man page files. I've added
a comment explaining what's going on (such a comment would have
prevented this mistake having been made in the first place).
One possibly weird thing here is that I have left both an
ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S)
recipes. This is 100% not going to break anything, these just print
two different progress messages while executing the recipes, but I'm
not sure if this is considered poor style or not. Maybe we're only
supposed to have a single ECHO_* per recipe?
Anyway, even if this is poor style, I figure it really is just a style
thing. We can tweak this later as needed. Otherwise, this commit
should fix the current issue blocking the next GDB release.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Nothing overrides tui_win_info::make_window, so remove the "virtual".
Tested by rebuilding.
|
|
This changes target_ops::thread_events and target_thread_events to use
'bool'. The callers were already doing this.
Tested by rebuilding.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
|
|
I re-ran make-target-delegates.py and discovered that the tree was out
of sync. This patch corrects the problem.
|
|
This commit a new section for the next release branch, and renames
the section of the current branch, now that it has been cut.
|
|
Now that the GDB 15 branch has been created,
this commit bumps the version number in gdb/version.in to
16.0.50.DATE-git
For the record, the GDB 15 branch was created
from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd.
Also, as a result of the version bump, the following changes
have been made in gdb/testsuite:
* gdb.base/default.exp: Change $_gdb_major to 16.
|
|
gdb.threads/attach-many-short-lived-threads.exp
When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run
regularly into PR26286:
...
(gdb) continue^M
Continuing.^M
[LWP ... exited]^M
...
[LWP ... exited]^M
^M
Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M
The program no longer exists.^M
(gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
break at break_fn: 1
...
Add a kfail for this, such that we have:
...
(gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \
break at break_fn: 1 (PRMS: threads/26286)
...
Reviewed-By: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
Tested on x86_64-linux.
|
|
In a remote testing setup, I saw this error:
~~~
(gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main
ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp.
ERROR: expected boolean value but got ""
while executing
"if { ![check_fork_catchpoints] } {
untested "follow-fork not supported"
return
}"
(file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434)
invoked from within
"source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
("uplevel" body line 1)
invoked from within
"uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp"
invoked from within
"catch "uplevel #0 source $test_file_name""
Remote debugging from host 172.0.1.3, port 37766
Killing process(es): 1171
Quit
~~~
The actual reason for this were some connection problems. Though the
function check_fork_catchpoints shouldn't return an empty string, especially
as it promises to always return 0 or 1. Fix that.
Approved-By: Tom Tromey <tom@tromey.com>
|
|
The code that was factored out from gdb.base/relativedebug.exp assumed that
libc has debug info and only determined that it doesn't if it saw a specific
message from GDB to that effect. In the process of factoring it into a
require predicate, I made it stricter by trying to make a specific
determination of whether or not debug info is available.
Pedro noticed that "It'll disable the testcase on systems that link with
their libc statically (even if has debug info), or systems that name their
libc something else." Which is something I hadn't considered.
This patch returns libc_has_debug_info to the original behaviour.
Also, remove a verbose message that is redundant with the $message
variable.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31700
Approved-By: Tom Tromey <tom@tromey.com>
|
|
Unfortunately the background DWARF reading series introduced a number
of races, as repored by thread sanitizer. This patch changes gdb to
disable this feature for the time being -- in particular for the gdb
15 release.
I've filed a bug and linked all the known races to it. Once those are
fixed we can re-enable this feature by default.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751
|
|
An Ada pretty-printer had a bug where its 'child' method returned a
gdb.Value rather than a tuple. Kévin suggested that the documentation
for this method could be improved to clarify this.
Reviewed-By: Kévin Le Gouguec <legouguec@adacore.com>
Approved-By: Eli Zaretskii <eliz@gnu.org>
|
|
Without this patch, the build chokes on:
../../src/gdb/windows-nat.c:384:21: error: field 'm_debug_event_pending' has incomplete type 'std::atomic<bool>'
384 | std::atomic<bool> m_debug_event_pending { false };
| ^~~~~~~~~~~~~~~~~~~~~
In file included from […gcc tree…]/include/c++/13.2.1/bits/shared_ptr_atomic.h:33,
from […gcc tree…]/include/c++/13.2.1/memory:81,
from ../../src/gdb/../gdbsupport/gdb_unique_ptr.h:23,
from ../../src/gdb/../gdbsupport/common-utils.h:26,
from ../../src/gdb/../gdbsupport/common-defs.h:199,
from ./../../src/gdb/defs.h:26,
from <command-line>:
[…gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic<bool>'
174 | struct atomic;
| ^~~~~~
make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1
Presumably windows-nat.c relied on objfiles.h including <atomic>,
which was undone in 2024-05-16 "gdb: remove unused includes in
objfiles.{c,h}" (f617661c110).
|
|
When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with
target board native-gdbserver, we run into:
...
(gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp.
ERROR: gdbserver does not support attach 4827 without extended-remote
while executing
"error "gdbserver does not support $command without extended-remote""
(procedure "gdb_test_multiple" line 51)
invoked from within
"gdb_test_multiple "attach $test_pid" "can spawn for attach" {
-re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." {
# Not permitte..."
(procedure "gdb_real__can_spawn_for_attach_1" line 27)
invoked from within
"gdb_real__can_spawn_for_attach_1"
...
The problem is that:
- can_spawn_for_attach_1 is a helper function for can_spawn_for_attach,
designed to be called only from that function, and
- can_spawn_for_attach_1 is a gdb_caching_proc, and consequently
test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls
can_spawn_for_attach_1 directly.
Fix this by copying the early-outs from can_spawn_for_attach to
can_spawn_for_attach_1.
Tested on x86_64-linux.
Reported-By: Simon Marchi <simark@simark.ca>
Reviewed-By: Alexandra Petlanova Hajkova <ahajkova@redhat.com>
|
|
I noticed that execute_fn_to_ui_file has an extra, unnecessary block.
This patch removes it.
|
