bfd/dwarf2.c:read_ranges compares bfd_vma values against -1UL, which
doesn't work correctly when long is 32-bit and bfd_vma is 64-bit
(observed as "nm -l" being very slow for mingw64 host; probably causes
issues on 32-bit hosts as well as IL32LLP64 cases such as mingw64).
Fix by using (bfd_vma) -1 in place of -1UL, as done elsewhere.
DAP specifies that a request can fail with the "notStopped" message if
the inferior is running but the request requires that it first be
stopped.
This patch implements this for gdb. Most requests are assumed to
require a stopped inferior, and the exceptions are noted by a new
'request' parameter.
You may notice that the implementation is a bit racy. I think this is
inherent -- unless the client waits for a stop event before sending a
request, the request may be processed at any time relative to a stop.
https://sourceware.org/bugzilla/show_bug.cgi?id=31037
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
ExecutionInvoker is no longer really needed, due to the previous DAP
refactoring. This patch removes it in favor of an ordinary function.
One spot (the 'continue' request) could still have used it, but is
more succinctly expressed as a lambda.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
Nearly every DAP request implementation forwards its work to the gdb
thread, using send_gdb_with_response. This patch refactors the
'request' decorator to make this automatic, and to provide some
parameters so that the unusual requests can express their needs as
well.
In a few spots this simplifies the code by removing an unnecessary
helper function. This could be done in more places as well if we
wanted.
The main motivation for this patch is that I thought it would be
helpful for cancellation. I am still working on that, but meanwhile
the parameterization of 'request' makes it easy to handle the
'notStopped' response as well.
Reviewed-by: Kévin Le Gouguec <legouguec@adacore.com>
DAP specifies a StackFrameFormat object that can be used to change how
the "name" part of a stack frame is constructed. While this output
can already be done in a nicer way (and also letting the client choose
the formatting), nevertheless it is in the spec, so I figured I'd
implement it.
While implementing this, I discovered that the current code does not
correctly preserve frame IDs across requests. I rewrote frame
iteration to preserve this, and it turned out to be simpler to combine
these patches.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30475
The AMD_DBGAPI_SCOPED_DEBUG_START_END macro in gdb/amd-dbgapi-target.c
is incorrectly controlled by "set debug infrun", while it should be
controlled by "set debug amd-dbgapi" instead. This commit fixes it.
Change-Id: I8ec2b1a4b9980c2d565a8aafd060ed070eeb3b29
PR gas/31043
"unsupported instruction ..." can mean about anything, and can also be
mistaken to mean something that isn't meant. Replace most of its uses by
more specific diagnostics,
While there also take the opportunity and purge the no longer used
invalid_register_operand enumerator.
{disp16} is invalid to use in 64-bit mode, while {disp32} is invalid to
use on pre-386 CPUs. The latter, also affecting other (real) prefixes,
further requires that like for insns we fully check the CPU flags; till
now only Cpu64/CpuNo64 were taken into consideration.
ELF-only functions don't need to be built when dealing with a non-ELF
target. md_section_align() also doesn't need to be a function when
dealing with non-AOUT targets. Similarly tc_fix_adjustable() can be a
simple macro when building non-ELF targets.
Furthermore x86_elf_abi is already used in ELF-only code sections, with
one exception. By adjusting that, the otherwise bogusly named variable
can also be confined to just ELF builds.
Simplify the code follow ing what check_{,q}word_reg() already do. This
the also eliminates a stale comment talking about a warning when an
error is raised. While there, correct a similarly stale comment in
check_qword_reg() while there.
Due to a missing check "crc32q %al, %rax" was wrongly translated to the
encoding of "crc32q %rax, %rax", rather than being rejected as invalid.
(The mnemonic suffix describes the source operand, not the destination
one.)
Note that check_{word,long}_reg() do not (currently) appear to require
similar amending, as there are no insn templates permitting an L or W
suffix and having an operand which allows for Reg8 and Reg64, but
neither Reg16 nor Reg32.
Previously the condition prevented shared objects from being relaxed.
To remove the limitation, we need to update program header size and
.eh_frame_hdr size before relaxation.
Remove uses of obstack in the code generating the libraries XML for
Windows and AIX. Use std::string instead. I'm not able to test this
change, unfortunately.
Change-Id: I28480913337e3fe8d6c31e551626931e6b1367ef
Approved-By: Tom Tromey <tom@tromey.com>
compile.exp generally does not work for me on Fedora 38. However, I
sent a GCC patch to fix the plugin crash. With that patch, I get this
error from one test in compile.exp:
gdb command line:1:22: warning: initialization of 'int (*)(int)' from incompatible pointer type 'int (*)()' [-Wincompatible-pointer-types]
This patch adds a cast to compile.exp. This makes the test pass.
Reviewed-by: Keith Seitz <keiths@redhat.com>
This commit:
commit 8f6c452b5a
Date: Sun Oct 15 22:48:42 2023 +0100
gdb: implement missing debug handler hook for Python
introduced a use of str.isascii(), which was only added in Python 3.7.
This commit switches to use curses.ascii.isascii(), as this was
available in 3.6.
The same is true for str.isalnum(), which is replaced with
curses.ascii.isalnum().
There should be no user visible changes after this commit.
This patch adds the permission model enhancement and memory
attribute index enhancement features and their corresponding
system registers in AArch64 assembler.
Permission Indirection Extension (FEAT_S1PIE, FEAT_S2PIE)
Permission Overlay Extension (FEAT_S1POE, FEAT_S2POE)
Memory Attribute Index Enhancement (FEAT_AIE)
Extension to Translation Control Registers (FEAT_TCR2)
These features are available by default from Armv9.4-A architecture.
This patch also adds support for:
1. FEAT_RASv2 feature and "ERXGSR_EL1" system register.
RASv2 feature is enabled by passing +rasv2 to -march
(eg: -march=armv8-a+rasv2).
2. FEAT_SCTLR2 and following system registers.
SCTLR2_EL1, SCTLR2_EL12, SCTLR2_EL2 and SCTLR2_EL3.
3. FEAT_FGT2 and following system registers.
HDFGRTR2_EL2, HDFGWTR2_EL2, HFGRTR2_EL2, HFGWTR2_EL2
4. FEAT_PFAR and following system registers.
PFAR_EL1, PFAR_EL2 and PFAR_EL12.
FEAT_RASv2, FEAT_SCTLR2, FEAT_FGT2 and FEAT_PFAR features are by default
enabled from Armv9.4-A architecture.
This patch also adds support for two read only system registers
id_aa64mmfr3_el1 and id_aa64mmfr4_el1, which are available from
Armv8-A Architecture.
This patch adds features to the Statistical Profiling Extension,
identified as FEAT_SPEv1p4, FEAT_SPE_FDS, and FEAT_SPE_CRR, which
are enabled by default from Armv9.4-A.
Also adds support for system register "pmsdsfr_el1".
Spotted that we'd gained two 'New commands' sections in our 'Changes
since GDB 14' NEWS file block. I've merged them together.
Also, one of these two sections was actually called 'New Commands',
however, all the other places in the NEWS file use 'New commands', so
I've changed to use that.
According to we have changed all E_MIPS_* to EF_MIPS_* in binutils
and glibc, we also need to change it here to keep same style.
We can refer to this commit record:
https://sourceware.org/pipermail/binutils/2023-October/129904.html
Approved-By: Pedro Alves <pedro@palves.net>
According to we have changed all E_MIPS_* to EF_MIPS_* in binutils
and glibc, we also need to change it here to keep same style.
We can refer to this commit record:
https://sourceware.org/pipermail/binutils/2023-October/129904.html
Approved-By: Pedro Alves <pedro@palves.net>
Simon noticed that gdb.threads/threads-after-exec.exp was racy. You
can consistenly reproduce it (at git hash
319b460545), with:
$ taskset -c 0 make check TESTS="gdb.threads/threads-after-exec.exp"
gdb.log shows:
(...)
Thread 3 "threads-after-e" hit Catchpoint 2 (exec'd .../gdb.threads/threads-after-exec/threads-after-exec), 0x00007ffff7fe3290
in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) PASS: gdb.threads/threads-after-exec.exp: continue until exec
info threads
Id Target Id Frame
* 3 process 1443269 "threads-after-e" 0x00007ffff7fe3290 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) FAIL: gdb.threads/threads-after-exec.exp: info threads
(...)
maint info linux-lwps
LWP Ptid Thread ID
1443269.1443269.0 1.3
(gdb) FAIL: gdb.threads/threads-after-exec.exp: maint info linux-lwps
The FAILs happen because the .exp file expects that after the exec,
the only thread has GDB thread number 1, but it has instead 3.
This is yet another case of zombie leader detection making things a
bit fuzzy.
In the passing case, we have:
continue
Continuing.
[New Thread 0x7ffff7bff640 (LWP 603183)]
[Thread 0x7ffff7bff640 (LWP 603183) exited]
process 603180 is executing new program: .../gdb.threads/threads-after-exec/threads-after-exec
While in the failing case, we have (note remarks on the rhs):
continue
Continuing.
[New Thread 0x7ffff7bff640 (LWP 600205)]
[Thread 0x7ffff7f95740 (LWP 600202) exited] <<< gdb deletes leader thread, thread 1.
[New LWP 600202] <<< gdb adds it back -- this is now thread 3.
[Thread 0x7ffff7bff640 (LWP 600205) exited]
process 600202 is executing new program: .../threads-after-exec/threads-after-exec
The testcase only has two threads, yet GDB presented the exec for
thread 3. This is GDB deleting the leader (the backend detected it
was zombie, due to the exec), and then adding the leader back when it
saw the exec event.
I've recorded some thoughts about this in PR gdb/31069.
For now, this commit just makes the testcase cope with the non-one
thread number, as the number is not important for what this test is
exercising.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31069
Change-Id: Id80b5c73f09c9e0005efeb494cca5d066ac3bbae
If you run gdb in the build tree without --data-directory, on a
program that does not have debug info, it will crash, because
gdbpy_handle_missing_debuginfo unconditionally uses gdb_python_module.
Other code in gdb using gdb_python_module checks it first and it
seemes harmless to do the same thing here. (gdb_python_initialized
does not cover this case so that python can be partially initialized
and still somewhat work.)
This changes ada-nested.exp to fix a test name (the test expects three
variables but is named "two"), and to iterate over all the variables
that are found. It also adds a workaround to a problem Tom de Vries
found with an older version of GNAT -- it emits a duplicate "x".
* testsuite/gas/elf/elf.exp (section2): Add -mpdr option to assembler command line for mips-irix targets.
* testsuite/gas/mips/elf-rel26.d: Add -mpdr command line option.
* testsuite/gas/mips/mips16-e.d: Likewise.
* testsuite/gas/mips/mips16-f.d: Likewise.
* testsuite/gas/mips/mips16-hilo-match.d: Likewise.
* testsuite/gas/mips/mips16-e-irix.d: Likewise.
* testsuite/gas/mips/call-nonpic-1.d: Adjust regexp to allow for mips-irix targets.
* testsuite/gas/mips/irix-no-pdr.d: New test file.
* testsuite/gas/mips/mips.exp: Run new test for mips-irix targets.
'runtest' complains about a path in a test name, from the new test
case py-missing-debug.exp.
This patch fixes the problem by providing an explicit test name to
gdb_test. I chose something very basic because the block in question
is already wrapped in with_test_prefix.
I found some "break" statements that follow "return" or a call to a
noreturn function. These aren't needed, and the compiler would warn
if they were. So, this patch removes them.
Tested by rebuilding.
On Linux, a thread can only be 16 bytes (including the trailing \0).
A user sent in a test case where this causes a truncated UTF-8
sequence, causing gdbserver to create invalid XML.
I went back and forth about different ways to solve this, and in the
end decided to fix it in gdbserver, with the reason being that it
seems important to generate correct XML for the <thread> response.
I am not totally sure whether the call to setlocale could have
unplanned consequences. This is needed, though, for nl_langinfo to
return the correct result.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30618
Kévin found a bug in an earlier version of this series that was based
on a misconception I had about Symbol.is_variable. This patch fixes
the documentation to explain the method a bit better.
Approved-By: Eli Zaretskii <eliz@gnu.org>
A co-worker requested that the DAP scope for a nested function's frame
also show the variables from outer frames. DAP doesn't directly
support this notion, so this patch arranges to put these variables
into the inner frames "Locals" scope.
I chose to do this only for DAP. For CLI and MI, gdb currently does
not do this, so this preserves the behavior.
Note that an earlier patch (see commit 4a1311ba) removed some code
that seemed to do something similar. However, that code did not
actually work.
While working on static links, I noticed that the DAP scopes code does
not handle the scenario where a frame decorator returns None. This
situation should be handled identically to a frame decorator returning
an empty iterator.
