Tom de Vries [Tue, 21 Nov 2023 10:44:07 +0000 (11:44 +0100)]
[gdb/tdep] Fix catching syscall execve exit for arm
When running test-case gdb.base/catch-syscall.exp on a pinebook (64-bit
aarch64 kernel, 32-bit userland) I run into:
...
(gdb) PASS: $exp: execve: syscall(s) execve appears in 'info breakpoints'
continue^M
Continuing.^M
^M
Catchpoint 18 (call to syscall execve), 0xf7726318 in execve () from \
/lib/arm-linux-gnueabihf/libc.so.6^M
(gdb) PASS: gdb.base/catch-syscall.exp: execve: program has called execve
continue^M
Continuing.^M
process 32392 is executing new program: catch-syscall^M
Cannot access memory at address 0xf77c6a7c^M
(gdb) FAIL: $exp: execve: syscall execve has returned
...
The memory error is thrown by arm_linux_get_syscall_number, when doing:
...
/* PC gets incremented before the syscall-stop, so read the
previous instruction. */
unsigned long this_instr =
read_memory_unsigned_integer (pc - 4, 4, byte_order_for_code);
...
The reason for the error is that we're stopped at the syscall exit of syscall
execve, and the pc is at the first insn of the new exec, which also happens to
be the first insn in the code segment, so consequently we cannot read the
previous insn.
Fix this by detecting the situation by looking at the register state, similar
to what is done in aarch64_linux_get_syscall_number.
Furthermore, catch the memory error by using safe_read_memory_unsigned_integer
and return -1 instead, matching the documented behaviour of
arm_linux_get_syscall_number.
Finally, rather than using a hardcoded constant 11, introduce an ad-hoc
arm_sys_execve.
Nick Clifton [Tue, 21 Nov 2023 09:26:19 +0000 (09:26 +0000)]
Fix: symbols eliminated by --gc-sections still trigger warnings for gnu.warning.SYM
PR 31067
* linker.c (_bfd_generic_link_add_one_symbol): When issuing a warning message, also display a message about the warning not being affected by garbage colleciton.
* ld.texi (Special Sections): New entry in the linker manual. Describes how the .gnu.warning and .gnu.warning.SYM sections behave.
In AIX, we are not able to see the message of a signal recieved if a debugee recieves a signal.
This is a patch to fix the signal handling done incorrectly in AIX.
We remove the status that represent program recieving a signal and allow host_status_to_waitstatus to
handle it for us.
This binary causes a segfault in GDB. GDB is trying to write the .dynamic
section into memory allocated on the stack with alloca(). However, the
allocation silently fails and the subsequent access to the memory is
causing the segfault. (On my node at least.)
Stack allocation is a bad idea for something of variable size that GDB has
no control over. So I changed the code to heap allocation.
In addition, I changed the type of sect_size to the type that bfd actually
returns.
There should be no user visible change after this.
Tom Tromey [Mon, 20 Nov 2023 16:31:32 +0000 (09:31 -0700)]
Restore .gdb_index v9 display in readelf
An earlier patch (commit b05efa39 "readelf..debug-dump=loc displays
bogus base addresses") inadvertently removed support for displaying
.gdb_index v9 sections.
This patch corrects the oversight. I tested this by using readelf on
an appropriate file.
Carl Love [Mon, 20 Nov 2023 16:13:22 +0000 (11:13 -0500)]
PowerPC: Fix test gdb.ada/finish-large.exp
Function Create_large returns a large data structure. On PowerPC, register
r3 contains the address of where the data structure to be returned is to
be stored. However, on exit the ABI does not guarantee that r3 has not
been changed. The GDB finish command prints the return value of the
function at the end of the function. GDB needs to use the
DW_TAG_call_site information to determine the value of r3 on entry to
the function to correctly print the return value at the end of the
function. The test must be compiled with -fvar-tracking for the
DW_TAG_call_site information to be included in the executable file.
This patch adds the -fvar-tracking option to the compile line if the
option is supported.
The patch fixes the one regression error for the test on PowerPC.
The patch has been tested on Power 10 and X86-64 with no regressions.
Nick Alcock [Tue, 7 Nov 2023 21:11:18 +0000 (21:11 +0000)]
libctf: adding CU mappings should be idempotent
When CTF finds conflicting types, it usually shoves each definition
into a CTF dictionary named after the compilation unit.
The intent of the obscure "cu-mapped link" feature is to allow you to
implement custom linkers that shove the definitions into other, more
coarse-grained units (say, one per kernel module, even if a module consists
of more than one compilation unit): conflicting types within one of these
larger components are hidden from name lookup so you can only look up (an
arbitrary one of) them by name, but can still be found by chasing type graph
links and are still fully deduplicated.
You do this by calling
ctf_link_add_cu_mapping (fp, "CU name", "bigger lump name"), repeatedly,
with different "CU name"s: the ctf_link() following that will put all
conflicting types found in "CU name"s sharing a "bigger lump name" into a
child dict in an archive member named "bigger lump name".
So it's clear enough what happens if you call it repeatedly with the same
"bigger lump name" more than once, because that's the whole point of it: but
what if you call it with the same "CU name" repeatedly?
This is meant to be the same as just doing the second of these, as if the
first was never called. Alas, this isn't what happens, and what you get is
instead a bit of an inconsistent mess: more or less, the first takes
precedence, which is the exact opposite of what we wanted.
Fix this to work the right way round.
(I plan to add support for CU-mapped links to GNU ld, mainly so that we can
properly *test* this machinery.)
libctf/ChangeLog:
* ctf-link.c (ctf_create_per_cu): Note the behaviour of
repeatedly adding FROMs.
(ctf_link_add_cu_mapping): Implement that behavour.
gdb: fix reread_symbols when an objfile has target: prefix
In this commit I update reopen_exec_file to correctly handle
executables with a target: prefix. Before this commit we used the
system 'stat' call, which obviously isn't going to work for files with
a target: prefix (files located on a possibly remote target machine).
By switching to bfd_stat we will use remote fileio to stat the remote
files, which means we should now correctly detect changes in a remote
executable.
The program_space::ebfd_mtime variable, with which we compare the
result of bfd_stat is set with a call to bfd_get_mtime, which in turn
calls bfd_stat, so comparing to the result of calling bfd_stat makes
sense (I think).
As I discussed in the commit f2c4f78c813a, if a BFD is an in-memory
BFD, then calling bfd_stat will always return 0, while bfd_get_mtime
will always return the time at which the BFD was created. As a result
comparing the results will always show the file having changed.
I don't believe that GDB can set the main executable to an in-memory
BFD object, so, in this commit, I simply assert that the executable is
not in-memory. If this ever changes then we would need to decide how
to handle this case -- always reload, or never reload. The assert
doesn't appear to trigger for our current test suite.
Andrew Burgess [Tue, 24 Oct 2023 16:54:51 +0000 (17:54 +0100)]
gdb: move all bfd_cache_close_all calls in gdb_bfd.c
In the following commit I ran into a problem. The next commit aims to
improve GDB's handling of the main executable being a file on a remote
target (i.e. one with a 'target:' prefix).
To do this I have replaced a system 'stat' call with a bfd_stat call.
However, doing this caused a regression in gdb.base/attach.exp.
The problem is that the bfd library caches open FILE* handles for bfd
objects that it has accessed, which is great for short-lived, non
interactive programs (e.g. the assembler, or objcopy, etc), however,
for GDB this caching causes us a problem.
If we open the main executable as a bfd then the bfd library will
cache the open FILE*. If some time passes, maybe just sat at the GDB
prompt, or with the inferior running, and then later we use bfd_stat
to check if the underlying, on-disk file has changed, then the bfd
library will actually use fstat on the underlying file descriptor.
This is of course slightly different than using system stat on with
the on-disk file name.
If the on-disk file has changed then system stat will give results for
the current on-disk file. But, if the bfd cache is still holding open
the file descriptor for the original on-disk file (from before the
change) then fstat will return a result based on the original file,
and so show no change as having happened.
This is a known problem in GDB, and so far this has been solved by
scattering bfd_cache_close_all() calls throughout GDB. But, as I
said, in the next commit I've made a change and run into a
problem (gdb.base/attach.exp) where we are apparently missing a
bfd_cache_close_all() call.
Now I could solve this problem by adding a bfd_cache_close_all() call
before the bfd_stat call that I plan to add in the next commit, that
would for sure solve the problem, but feels a little crude.
Better I think would be to track down where the bfd is being opened
and add a corresponding bfd_cache_close_all() call elsewhere in GDB
once we've finished doing whatever it is that caused us to open the
bfd in the first place.
This second solution felt like the better choice, so I tracked the
problem down to elf_locate_base and fixed that. But that just exposed
another problem in gdb_bfd_map_section which was also re-opening the
bfd, so I fixed this (with another bfd_cache_close_all() call), and
that exposed another issue in gdbarch_lookup_osabi... and at this
point I wondered if I was approaching this problem the wrong way...
.... And so, I wonder, is there a _better_ way to handle these
bfd_cache_close_all() calls?
I see two problems with the current approach:
1. It's fragile. Folk aren't always aware that they need to clear
the bfd cache, and this feels like something that is easy to
overlook in review. So adding new code to GDB can innocently touch
a bfd, which populates the cache, which will then be a bug that can
lie hidden until an on-disk file just happens to change at the wrong
time ... and GDB fails to spot the change. Additionally,
2. It's in efficient. The caching is intended to stop the bfd
library from continually having to re-open the on-disk file. If we
have a function that touches a bfd then often that function is the
obvious place to call bfd_cache_close_all. But if a single GDB
command calls multiple functions, each of which touch the bfd, then
we will end up opening and closing the same on-disk file multiple
times. It feels like we would be better postponing the
bfd_cache_close_all call until some later point, then we can benefit
from the bfd cache.
So, in this commit I propose a new approach. We now clear the bfd
cache in two places:
(a) Just before we display a GDB prompt. We display a prompt after
completing a command, and GDB is about to enter an idle state
waiting for further input from the user (or in async mode, for an
inferior event). If while we are in this idle state the user
changes the on-disk file(s) then we would like GDB to notice this
the next time it leaves its idle state, e.g. the next time the user
executes a command, or when an inferior event arrives,
(b) When we resume the inferior. In synchronous mode, resuming the
inferior is another time when GDB is blocked and sitting idle, but
in this case we don't display a prompt. As with (a) above, when an
inferior event arrives we want GDB to notice any changes to on-disk
files.
It turns out that there are existing observers for both of these
cases (before_prompt and target_resumed respectively), so my initial
thought was that I should attach to these observers in gdb_bfd.c, and
in both cases call bfd_cache_close_all().
And this does indeed solve the gdb.base/attach.exp problem that I see
with the following commit.
However, I see a problem with this solution.
Both of the observers I'm using are exposed through the Python API as
events that a user can hook into. The user can potentially run any
GDB command (using gdb.execute), so Python code might end up causing
some bfds to be reopened, and inserted into the cache.
To solve this one solution would be to add a bfd_cache_close_all()
call into gdbpy_enter::~gdbpy_enter(). Unfortunately, there's no
similar enter/exit object for Guile, though right now Guile doesn't
offer the same event API, so maybe we could just ignore that
problem... but this doesn't feel great.
So instead, I think a better solution might be to not use observers
for the bfd_cache_close_all() calls. Instead, I'll call
bfd_cache_close_all() directly from core GDB after we've notified the
before_prompt and target_resumed observers, this was we can be sure
that the cache is cleared after the observers have run, and before GDB
enters an idle state.
This commit also removes all of the other bfd_cache_close_all() calls
from GDB. My claim is that these are no longer needed.
The previous commit introduced some local variables to make some if
statements simpler. This commit uses them more liberally throughout the
process_event_stop_test in order to simplify the function a little more.
No functional changes are expected.
gdb/record: print frame information when exiting a recursive call
Currently, when GDB is reverse stepping out of a function into the same
function due to a recursive call, it doesn't print frame information, as
reported by PR record/29178. This happens because when the inferior
leaves the current frame, GDB decides to refresh the step information,
clobbering the original step_frame_id, making it impossible to figure
out later on that the frame has been changed.
This commit changes GDB so that, if we notice we're in this exact
situation, we won't refresh the step information.
Because of implementation details, this change can cause some debug
information to be read when it normally wouldn't before, which showed up
as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that
isn't a problem, the test was changed to allow for the new output.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178 Approved-By: Tom Tromey <tom@tromey.com>
Jose E. Marchesi [Sat, 18 Nov 2023 17:12:44 +0000 (18:12 +0100)]
gas: bpf: do not allow referring to register names as symbols in operands
2023-11-18 Jose E. Marchesi <jemarch@gnu.org>
* config/tc-bpf.c (parse_bpf_register): Move before
bpf_parse_name.
(bpf_parse_name): Do not allow using symbols that are also
register names as operands in pseudo-c syntax.
* testsuite/gas/bpf/regs-for-symbols-pseudoc.d: New file.
* testsuite/gas/bpf/regs-for-symbols-pseudoc.s: Likewise.
* testsuite/gas/bpf/regs-for-symbols-pseudoc.l: Likewise.
* doc/c-bpf.texi (BPF Registers): Document that it is not possible
to refer to register names as symbols in instruction operands.
David Faust [Thu, 16 Nov 2023 17:35:03 +0000 (09:35 -0800)]
bpf: avoid creating wrong symbols while parsing
To support the "pseudo-C" asm dialect in BPF, the BPF parser must often
attempt multiple different templates for a single instruction. In some
cases this can cause the parser to incorrectly parse part of the
instruction opcode as an expression, which leads to the creation of a
new undefined symbol.
Once the parser recognizes the error, the expression is discarded and it
tries again with a new instruction template. However, symbols created
during the process are added to the symbol table and are not removed
even if the expression is discarded.
This is a problem for BPF: generally the assembled object will be loaded
directly to the Linux kernel, without being linked. These erroneous
parser-created symbols are rejected by the kernel BPF loader, and the
entire object is refused.
This patch remedies the issue by tentatively creating symbols while
parsing instruction operands, and storing them in a temporary list
rather than immediately inserting them into the symbol table. Later,
after the parser is sure that it has correctly parsed the instruction,
those symbols are committed to the real symbol table.
This approach is modeled directly after Jan Beulich's patch for RISC-V:
Many thanks to Jan for recognizing the problem as similar, and pointing
me to that patch.
gas/
* config/tc-bpf.c (parsing_insn_operands): New.
(parse_expression): Set it here.
(deferred_sym_rootP, deferred_sym_lastP): New.
(orphan_sym_rootP, orphan_sym_lastP): New.
(bpf_parse_name): New.
(parse_error): Clear deferred symbol list on error.
(md_assemble): Clear parsing_insn_operands. Commit deferred
symbols to symbol table on successful parse.
* config/tc-bpf.h (md_parse_name): Define to...
(bpf_parse_name): ...this. New prototype.
* testsuite/gas/bpf/asm-extra-sym-1.s: New test source.
* testsuite/gas/bpf/asm-extra-sym-1.d: New test.
* testsuite/gas/bpf/bpf.exp: Run new test.
Simon Marchi [Sun, 5 Nov 2023 04:47:26 +0000 (04:47 +0000)]
gdb: remove get_current_regcache
Remove get_current_regcache, inlining the call to get_thread_regcache in
callers. When possible, pass the right thread_info object known from
the local context. Otherwise, fall back to passing `inferior_thread ()`.
This makes the reference to global context bubble up one level, a small
step towards the long term goal of reducing the number of references to
global context (or rather, moving those references as close as possible
to the top of the call tree).
Simon Marchi [Fri, 17 Nov 2023 19:55:58 +0000 (19:55 +0000)]
gdb: remove regcache's address space
While looking at the regcache code, I noticed that the address space
(passed to regcache when constructing it, and available through
regcache::aspace) wasn't relevant for the regcache itself. Callers of
regcache::aspace use that method because it appears to be a convenient
way of getting the address space for a thread, if you already have the
regcache. But there is always another way to get the address space, as
the callers pretty much always know which thread they are dealing with.
The regcache code itself doesn't use the address space.
This patch removes anything related to address_space from the regcache
code, and updates callers to get it from the thread in context. This
removes a bit of unnecessary complexity from the regcache code.
The current get_thread_arch_regcache function gets an address_space for
the given thread using the target_thread_address_space function (which
calls the target_ops::thread_address_space method). This suggest that
there might have been the intention of supporting per-thread address
spaces. But digging through the history, I did not find any such case.
Maybe this method was just added because we needed a way to get an
address space from a ptid (because constructing a regcache required an
address space), and this seemed like the right way to do it, I don't
know.
The only implementations of thread_address_space and
process_stratum_target::thread_address_space and
linux_nat_target::thread_address_space, which essentially just return
the inferior's address space. And thread_address_space is only used in
the current get_thread_arch_regcache, which gets removed. So, I think
that the thread_address_space target method can be removed, and we can
assume that it's fine to use the inferior's address space everywhere.
Callers of regcache::aspace are updated to get the address space from
the relevant inferior, either using some context they already know
about, or in last resort using the current global context.
So, to summarize:
- remove everything in regcache related to address spaces
- in particular, remove get_thread_arch_regcache, and rename
get_thread_arch_aspace_regcache to get_thread_arch_regcache
- remove target_ops::thread_address_space, and
target_thread_address_space
- adjust all users of regcache::aspace to get the address space another
way
Tom Tromey [Fri, 17 Nov 2023 18:04:08 +0000 (11:04 -0700)]
Remove extraneous blocks from dwarf2/read.c:new_symbol
dwarf2/read.c:new_symbol has some extra braces in a couple of 'case's.
These read weirdly to me, and since they aren't necessary, this patch
removes the braces and reindents the bodies. Tested by rebuilding.
Joseph Myers [Fri, 17 Nov 2023 17:04:14 +0000 (17:04 +0000)]
Fix read_ranges for 32-bit long
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.
Tom Tromey [Tue, 7 Nov 2023 15:44:44 +0000 (08:44 -0700)]
Implement the notStopped DAP response
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.
Tom Tromey [Mon, 6 Nov 2023 21:29:06 +0000 (14:29 -0700)]
Remove ExecutionInvoker
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.
Tom Tromey [Mon, 6 Nov 2023 20:31:17 +0000 (13:31 -0700)]
Automatically run (most) DAP requests in gdb thread
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.
Tom Tromey [Fri, 6 Oct 2023 19:40:39 +0000 (13:40 -0600)]
Handle StackFrameFormat in DAP
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.
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.
Jan Beulich [Fri, 17 Nov 2023 10:24:12 +0000 (11:24 +0100)]
x86: improve a few diagnostics
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.
Jan Beulich [Fri, 17 Nov 2023 10:23:20 +0000 (11:23 +0100)]
x86: CPU-qualify {disp16} / {disp32}
{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.
Jan Beulich [Fri, 17 Nov 2023 10:20:25 +0000 (11:20 +0100)]
x86: fold conditionals in check_long_reg()
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.
Jan Beulich [Fri, 17 Nov 2023 10:20:06 +0000 (11:20 +0100)]
x86-64: extend expected-size check in check_qword_reg()
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.
Simon Marchi [Wed, 12 Apr 2023 20:27:01 +0000 (16:27 -0400)]
gdb: remove two uses of obstack
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>
Tom Tromey [Wed, 15 Nov 2023 19:42:52 +0000 (12:42 -0700)]
Fix small bug in compile.exp
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.
aarch64: Add support for VMSA feature enhancements.
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.
aarch64: Add support to new features in RAS extension.
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.
aarch64: Add features to the Statistical Profiling Extension.
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".
Andrew Burgess [Thu, 16 Nov 2023 11:11:30 +0000 (11:11 +0000)]
gdb/NEWS: merge two 'New commands' sections
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.
Ying Huang [Wed, 15 Nov 2023 02:30:49 +0000 (10:30 +0800)]
sim: mips: Change E_MIPS_* to EF_MIPS_*
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
Ying Huang [Wed, 15 Nov 2023 02:30:48 +0000 (10:30 +0800)]
gdb: mips: Change E_MIPS_* to EF_MIPS_*
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
$ 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.
Tom Tromey [Wed, 15 Nov 2023 13:48:55 +0000 (06:48 -0700)]
Check gdb_python_module in gdbpy_handle_missing_debuginfo
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.)
Tom Tromey [Wed, 15 Nov 2023 14:50:19 +0000 (07:50 -0700)]
Minor cleanups in ada-nested.exp
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".
YunQiang Su [Wed, 15 Nov 2023 10:57:48 +0000 (10:57 +0000)]
MIPS: Fix Irix gas testcases about pdr section
* 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.
Tom Tromey [Tue, 14 Nov 2023 18:47:27 +0000 (11:47 -0700)]
Remove path name from test case
'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.
Tom Tromey [Tue, 14 Nov 2023 17:37:55 +0000 (10:37 -0700)]
Remove some redundant "break"s
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.
Tom Tromey [Thu, 13 Jul 2023 23:28:48 +0000 (17:28 -0600)]
Filter invalid encodings from Linux thread names
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.
Tom Tromey [Mon, 30 Oct 2023 16:52:20 +0000 (10:52 -0600)]
Handle the static link in FrameDecorator
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.
Tom Tromey [Mon, 30 Oct 2023 16:23:35 +0000 (10:23 -0600)]
Fix a bug in DAP scopes code
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.
Tom Tromey [Tue, 24 Oct 2023 13:59:51 +0000 (07:59 -0600)]
Move follow_static_link to frame.c
This moves the follow_static_link function to frame.c and exports it
for use elsewhere. The API is changed slightly to make it more
generically useful.
Tom de Vries [Tue, 14 Nov 2023 14:45:18 +0000 (15:45 +0100)]
[gdb/tui] Factor out tui_noscroll_window et al
I noticed that tui_locator_window has an empty do_scroll_vertical and
do_scroll_horizontal, like tui_cmd_window, but unlike tui_cmd_window doesn't
have:
...
bool can_scroll () const override
{
return false;
}
...
I suspect that it probably doesn't matter, but regardless it's good to have
the same implementations of basic properties in all windows.
Ensure this by adding a class tui_noscroll_window, that has:
- an empty do_scroll_vertical and do_scroll_horizontal, and
- a can_scroll returning false
which both tui_locator_window and tui_cmd_window inherit.
Make all methods final to ensure no accidental overrides are left in the
inheriting classes.
Likewise add new classes representing basic window properties:
- tui_nofocus_window,
- tui_oneline_window,
- tui_nobox_window,
- tui_norefresh_window, and
- tui_always_visible_window.
The changes are only a refactoring, apart from adding the "final", which does
limit the range of behaviours for subclasses.
Refactor the ARGTYPES regular expression in make-target-delegates.py
to eliminate '.*' for better control on what is matched. Also,
simplify the "E" match group, for which the optional SYMBOL becomes
redundant because that case can be matched by the "T" group.
After applying this patch, running './make-target-delegates.py' does not
change anything in 'target-delegates.c'.
I ran './make-target-delegates.py' and there is one minor difference,
where an older style declaration is converted to a newer
initialization style. Add this change.
I ran into the following FAIL:
...
(gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls
continue^M
Continuing.^M
^M
Catchpoint 2 (call to syscall clone), clone () at \
../sysdeps/unix/sysv/linux/x86_64/clone.S:78^M
warning: 78 ../sysdeps/unix/sysv/linux/x86_64/clone.S: \
No such file or directory^M
(gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue
...
All but one regexps in the .exp file use "clone\[23\]?" with "?" to
also accept "clone", except the failing case. This commit fixes that
case to also use "?".
Furthermore, there are FAILs like this:
...
(gdb) PASS: gdb.threads/stepi-over-clone.exp: third_thread=false: \
non-stop=on: displaced=off: i=0: continue
stepi^M
[New Thread 0x7ffff7ff8700 (LWP 15301)]^M
Hello from the first thread.^M
78 in ../sysdeps/unix/sysv/linux/x86_64/clone.S^M
(gdb) XXX: Consume the initial command
XXX: Consume new thread line
XXX: Consume first worker thread message
FAIL: gdb.threads/stepi-over-clone.exp: third_thread=false: non-stop=on: \
displaced=off: i=0: stepi
...
because this output is expected instead:
...
Hello from the first thread.^M
0x00000000004212cd in clone3 ()^M
...
The root cause for the difference is the presence of .debug_line info for
clone.
Fix this by updating the relevant regexps.
Tested on x86_64-linux, specifically:
- openSUSE Leap 15.4 (where the FAILs where observed), and
- openSUSE Tumbleweed (where the FAILs where not observed).
Co-Authored-By: Pedro Alves <pedro@palves.net> Approved-By: Pedro Alves <pedro@palves.net>
Change-Id: I74ca9e7d4cfe6af294fd50e8c509fcbad289b78c
Andrew Burgess [Sun, 15 Oct 2023 21:48:42 +0000 (22:48 +0100)]
gdb: implement missing debug handler hook for Python
This commit builds on the previous commit, and implements the
extension_language_ops::handle_missing_debuginfo function for Python.
This hook will give user supplied Python code a chance to help find
missing debug information.
The implementation of the new hook is pretty minimal within GDB's C++
code; most of the work is out-sourced to a Python implementation which
is modelled heavily on how GDB's Python frame unwinders are
implemented.
The following new commands are added as commands implemented in
Python, this is similar to how the Python unwinder commands are
implemented:
info missing-debug-handlers
enable missing-debug-handler LOCUS HANDLER
disable missing-debug-handler LOCUS HANDLER
To make use of this extension hook a user will create missing debug
information handler objects, and registers these handlers with GDB.
When GDB encounters an objfile that is missing debug information, each
handler is called in turn until one is able to help. Here is a
minimal handler that does nothing useful:
import gdb
import gdb.missing_debug
class MyFirstHandler(gdb.missing_debug.MissingDebugHandler):
def __init__(self):
super().__init__("my_first_handler")
def __call__(self, objfile):
# This handler does nothing useful.
return None
Returning None from the __call__ method tells GDB that this handler
was unable to find the missing debug information, and GDB should ask
any other registered handlers.
By extending the __call__ method it is possible for the Python
extension to locate the debug information for objfile and return a
value that tells GDB how to use the information that has been located.
Possible return values from a handler:
- None: This means the handler couldn't help. GDB will call other
registered handlers to see if they can help instead.
- False: The handler has done all it can, but the debug information
for the objfile still couldn't be found. GDB will not call
any other handlers, and will continue without the debug
information for objfile.
- True: The handler has installed the debug information into a
location where GDB would normally expect to find it. GDB
should look again for the debug information.
- A string: The handler can return a filename, which is the file
containing the missing debug information. GDB will load
this file.
When a handler returns True, GDB will look again for the debug
information, but only using the standard built-in build-id and
.gnu_debuglink based lookup strategies. It is not possible for an
extension to trigger another debuginfod lookup; the assumption is that
the debuginfod server is remote, and out of the control of extensions
running within GDB.
Handlers can be registered globally, or per program space. GDB checks
the handlers for the current program space first, and then all of the
global handles. The first handler that returns a value that is not
None, has "handled" the objfile, at which point GDB continues.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Tom Tromey <tom@tromey.com>
Andrew Burgess [Fri, 13 Oct 2023 15:48:36 +0000 (16:48 +0100)]
gdb: add an extension language hook for missing debug info
This commit adds a new extension_language_ops hook which allows an
extension to handle the case where GDB can't find a separate debug
information file for a particular objfile.
This commit doesn't actually implement the hook for any of GDB's
extension languages, the next commit will do that. This commit just
adds support for the hook to extension-priv.h and extension.[ch], and
then reworks symfile-debug.c to call the hook.
Right now the hook will always return its default value, which means
GDB should do nothing different. As such, there should be no user
visible changes after this commit.
I'll give a brief description of what the hook does here so that we
can understand the changes in symfile-debug.c. The next commit adds a
Python implementation for this new hook, and gives a fuller
description of the new functionality.
Currently, when looking for separate debug information GDB tries three
things, in this order:
1. Use the build-id to find the required debug information,
2. Check for .gnu_debuglink section and use that to look up the
required debug information,
3. Check with debuginfod to see if it can supply the required
information.
The new extension_language_ops::handle_missing_debuginfo hook is
called if all three steps fail to find any debug information. The
hook has three possible return values:
a. Nothing, no debug information is found, GDB continues without the
debug information for this objfile. This matches the current
behaviour of GDB, and is the default if nothing is implementing this
new hook,
b. Install debug information into a location that step #1 or #2
above would normally check, and then request that GDB repeats steps
#1 and #2 in the hope that GDB will now find the debug information.
If the debug information is still not found then GDB carries on
without the debug information. If the debug information is found
the GDB loads it and carries on,
c. Return a filename for a file containing the required debug
information. GDB loads the contents of this file and carries on.
The changes in this commit mostly involve placing the core of
objfile::find_and_add_separate_symbol_file into a loop which allows
for steps #1 and #2 to be repeated.
We take care to ensure that debuginfod is only queried once, the first
time through. The assumption is that no extension is going to be able
to control the replies from debuginfod, so there's no point making a
second request -- and as these requests go over the network, they
could potentially be slow.
The warnings that find_and_add_separate_symbol_file collects are
displayed only once assuming that no debug information is found. If
debug information is found, even after the extension has operated,
then the warnings are not shown; remember, these are warnings from GDB
about failure to find any suitable debug information, so it makes
sense to hide these if debug information is found.
This commit splits objfile::find_and_add_separate_symbol_file into
some separate helper functions. My hope is that the steps for looking
up separate debug information are now clearer.
In a later commit I'm going to extend
objfile::find_and_add_separate_symbol_file, with some additional
logic, so starting with a simpler function will make the following
changes easier.
When reading objfile::find_and_add_separate_symbol_file after this
commit, you might be tempted to think that removing the `has_dwarf`
local variable would be a good additional cleanup. After the next
commit though it makes more sense to retain this local, so I've left
this in place for now.
There should be no user visible changes after this commit.
Andrew Burgess [Fri, 13 Oct 2023 08:50:33 +0000 (09:50 +0100)]
gdb: merge debug symbol file lookup code from coffread & elfread paths
This commit merges the code that looks for and loads the separate
debug symbol files from coffread.c and elfread.c. The factored out
code is moved into a new objfile::find_and_add_separate_symbol_file()
method.
For the elfread.c path there should be no user visible changes after
this commit.
For the coffread.c path GDB will now attempt to perform a debuginfod
lookup for the missing debug information, assuming that GDB can find a
build-id in the COFF file.
I don't know if COFF files can include a build-id, but I the existing
coffread.c code already includes a call to
find_separate_debug_file_by_build-id, so I know that it is at least OK
for GDB to ask a COFF file for a build-id. If the COFF file doesn't
include a build-id then the debuginfod lookup code will not trigger
and the new code is harmless.
If the COFF file does include a build-id, then we're going to end up
asking debuginfod for the debug file. As build-ids should be unique,
this should be harmless, even if debuginfod doesn't contain any
suitable debug data, it just costs us one debuginfod lookup, so I'm
not too worried about this for now.
As with the previous commit, I've done some minimal testing using the
mingw toolchain on a Linux machine, GDB seems to still access the
split debug information just fine.
the logic for when we try to load a separate debug file in elfread.c
was extended. The new code checks that the objfile doesn't already
have a separate debug objfile linked to it, and that the objfile isn't
itself a separate debug objfile for some other objfile.
The coffread code wasn't extended at the same time.
I don't know if it's possible for the coffread code to get into the
same state where these checks are needed, but I don't see why having
these checks would be a problem. In a later commit I plan to merge
this part of the elfread and coffread code, so bringing these two
pieces of code into line first makes that job easier.
I've tested this with a simple test binary compiled with the mingw
toolchain on a Linux host. After compiling the binary and splitting
out the debug info GDB still finds and loads the separate debug info.
Nick Clifton [Tue, 14 Nov 2023 10:57:58 +0000 (10:57 +0000)]
Improve objdump's handling of compressed sections.
PR 31062
* objdump.c (decompressed_dumps): New local variable. (usage): Mention the -z/--decompress option. (long_options): Add --decompress. (dump_section_header): Add "COMPRESSED" to the Flags field of any compressed section. (dump_section): Warn users when dumping a compressed section. (display_any_bfd): Decompress the section if decompressed_dumps is true. (main): Handle the -z/--decompress option.
* NEWS: Mention the new feature.
* doc/binutils.texi: Document the new feature.
* testsuite/binutils-all/objdump.s: Update expected output.
* testsuite/binutils-all/objdump.exp: Add test of -Z -s.
* testsuite/binutils-all/objdump.Zs: New file.
* readelf.c (maybe_expand_or_relocate_section): New function. Contains common code found in dump functions. Adds a note message if a compressed section is not being decompressed. (dump_section_as_strings): Use new function. (dump_section_as_bytes): Likewise.
Tom de Vries [Mon, 13 Nov 2023 20:22:50 +0000 (21:22 +0100)]
[gdb/tui] Don't include border_width in left_margin
Currently left_margin does not match its documentation:
...
/* Return the size of the left margin space, this is the space used to
display things like breakpoint markers. */
int left_margin () const
{ return box_width () + TUI_EXECINFO_SIZE + extra_margin (); }
...
It is stated that the left margin is reserved to display things, but
the box_width is not used for that.
Fix this by dropping box_width () from the left_margin calculation.
Tom de Vries [Mon, 13 Nov 2023 20:22:50 +0000 (21:22 +0100)]
[gdb/tui] Add tui_win_info::{box_width,box_size}
In tui_source_window::set_contents we have:
...
/* Take hilite (window border) into account, when
calculating the number of lines. */
int nlines = height - 2;
...
The '2' represents the total size of the window border (or box, in can_box
terms), in this case one line at the top and one line at the bottom.
Likewise, '1' is used to represent the width of the window border.
Introduce new functions:
- tui_win_info::box_width () and
- tui_win_info::box_size ()
that can be used instead instead of these hardcoded constants.
Implement these such that they return 0 when can_box () == false.
Tested patch completeness by making all windows unboxed:
...
@@ -85,7 +85,7 @@ struct tui_win_info
/* Return true if this window can be boxed. */
virtual bool can_box () const
{
- return true;
+ return false;
}
int box_width () const
...
and test-driving TUI.
This required eliminating an assert in
tui_source_window_base::show_source_content, I've included that part as well.
Tom de Vries [Mon, 13 Nov 2023 20:22:50 +0000 (21:22 +0100)]
[gdb/tui] Refactor prefresh call in tui_source_window_base::refresh_window
Currently the call to prefresh in tui_source_window_base::refresh_window looks
like:
...
prefresh (m_pad.get (), 0, pad_x, y + 1, x + left_margin,
y + m_content.size (), x + left_margin + view_width - 1);
...
This is hard to parse. It's not obvious what the arguments mean, and there's
repetition in the argument calculation.
Fix this by rewriting the call as follows:
- use sminrow, smincol, smaxrow and smaxcol variables for the last
4 arguments, and
- calculate the smaxrow and smaxcol variables based on the sminrow and
smincol variables.
Carl Love [Mon, 13 Nov 2023 19:14:08 +0000 (14:14 -0500)]
Fix the gdb.ada/inline-section-gc.exp test
The original intention of the test appears to be checking to make sure
setting a breakpoint in an inlined function didn't set multiple
breakpoints where one of them was at address 0.
The gdb.ada/inline-section-gc.exp test may pass or fail depending on the
version of gnat. Per the discussion on IRC, the ada inlining appears to
have some target dependencies. In this test there are two functions,
callee and caller. Function calee is inlined into caller. The test sets
a breakpoint in function callee. The reported location where the
breakpoint is set may be at the requested location in callee or the
location in caller after callee has been inlined. The test needs to
accept either location as correct provided the breakpoint address is not
zero.
This patch checks to see if the reported breakpoint is in function callee
or function caller and fails if the breakpoint address is 0x0. The line
number where the breakpoint is set will match the requested line if the
breakpoint location is reported is callee.adb. If the breakpoint is
reported in caller.adb, the line number in caller is the breakpoint
location in callee where it is inlined into caller.
This patch fixes the single regression failure for the test on PowerPC.
It does not introduce any failures on X86-64.
Mark Wielaard [Sun, 12 Nov 2023 16:51:58 +0000 (17:51 +0100)]
Regenerate gas/config.in and ld/configure
commit d173146d9 "MIPS: Change all E_MIPS_* to EF_MIPS_*"
changed gas/config.in to rename USE_E_MIPS_ABI_O32 to USE_EF_MIPS_ABI_O32
this new name sorts differently when regenerating gas/config.in
commit e922d1eaa "Add ability to change linker warning messages into
errors when reporting executable stacks and/or executable segments."
Introduced two new help strings for --enable-error-execstack and
--enable-error-rwx-segments in configure.ac which weren't included
in ld/configure when regenerated.
projects / thirdparty / binutils-gdb.git / log
