gdbserver isn't sending expedited registers with its stop reply packets
anymore. The problem is with how the constructor of the
expedited_registers std::vector is called:
The intent of the expedited_registers initialization in
aarch64_linux_read_description is to create a vector with capacity for 6
elements, but that's not how the std::vector constructor works.
Instead it creates a vector pre-populated with 6 elements initialized
with the default value for the type of the elements, and thus the first
6 elements are null pointers. The actual expedited registers are added
starting at the 7th element.
This causes init_target_desc to consider that the expedite_regs list is
empty, since it stops checking at the first nullptr element. The end
result is that gdbserver doesn't send any expedited registers to GDB in
its stop replies.
Fix by not specifying an element count when declaring the vector.
Tested for regressions on aarch64-linux-gnu native-extended-remote.
Lulu Cai [Thu, 5 Sep 2024 02:20:49 +0000 (10:20 +0800)]
LoongArch: Fixed ABI v1.00 TLS dynamic relocation generation bug
Commit "b67a17aa7c0c478a" modified the logic of allocating dynamic
relocation space for TLS GD/IE, but only modified the logic of
generation dynamic relocations for TLS GD/IE in ABI v2.00. When
linking an object file of ABI v1.00 with bfd ld of ABI v2.00, it
will cause an assertion failure.
Modified the dynamic relocation generation logic of TLS GD/IE
in ABI v1.00 to be consistent with ABI v2.00.
Tom Tromey [Fri, 30 Aug 2024 17:32:20 +0000 (11:32 -0600)]
Improve comments in dwarf2/parent-map.h
I noticed that the comments for class parent_map aren't very clear.
This patch attempts to fix this, and also clarifies a point on
parent_map_map::add_map.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Tue, 20 Aug 2024 16:42:46 +0000 (17:42 +0100)]
libiberty: sync with gcc
This syncs binutils-gdb/libiberty with gcc/libiberty up to GCC commit 64028d626a50410dbf29. This picks up the follow 3 GCC commits:
ea238096883 (gcc-delete-unused-func) libiberty/argv.c: remove only_whitespace 5e1d530da87 (gcc-buildargv) libiberty/buildargv: handle input consisting of only white space a87954610f5 libiberty/buildargv: POSIX behaviour for backslash handling
Andrew Burgess [Wed, 14 Aug 2024 14:16:46 +0000 (15:16 +0100)]
gdb: implement ::re_set method for catchpoint class
It is possible to attach a condition to a catchpoint. This can't be
done when the catchpoint is created, but can be done with the
'condition' command, this is documented in the GDB manual:
You can also use the 'if' keyword with the 'watch' command. The
'catch' command does not recognize the 'if' keyword; 'condition' is the
only way to impose a further condition on a catchpoint.
A GDB crash was reported against Fedora GDB where a user had attached
a condition to a catchpoint and then restarted the inferior. When the
catchpoint was hit GDB would immediately segfault. I was able to
reproduce the failure on upstream GDB:
(gdb) file ./some/binary
(gdb) catch syscall write
(gdb) run
...
Catchpoint 1 (returned from syscall write), 0x00007ffff7b594a7 in write () from /lib64/libc.so.6
(gdb) condition 1 $_streq((char *) $rsi, "foobar") == 0
(gdb) run
...
Fatal signal: Segmentation fault
...
What happened here is that on the system in question we had debug
information available for both the main application and also for
libc.
When the condition was attached GDB was stopped inside libc and as the
debug information was available GDB found a reference to the 'char'
type (for the cast) inside libc's debug information.
When the inferior is restarted GDB discards all of the objfiles
associated with shared libraries, and this includes libc. As such the
'char' type, which is objfile owned, is discarded and the reference to
it from the catchpoint's condition expression becomes invalid.
Now, if it were a breakpoint instead of a catchpoint, what would
happen is that after the shared library objfiles had been discarded
we'd call the virtual breakpoint::re_set method on the breakpoint, and
this would update the breakpoint's condition expression. This is
because user breakpoints are actually instances of the code_breakpoint
class and the code_breakpoint::re_set method contains the code to
recompute the breakpoint's condition expression.
However, catchpoints are instances of the catchpoint class which
inherits from the base breakpoint class. The catchpoint class does
not override breakpoint::re_set, and breakpoint::re_set is empty!
The consequence of this is that catchpoint condition expressions are
never recomputed, and the dangling pointer to the now deleted, objfile
owned type 'char' is left around, and, when the catchpoint is hit, the
invalid pointer is used when GDB tries to evaluate the condition
expression.
In this commit I have implemented catchpoint::re_set. This is pretty
simple and just recomputes the condition expression as you'd expect.
If the condition doesn't evaluate then the catchpoint is marked as
disabled_by_cond.
I have also made breakpoint::re_set pure virtual. With the addition
of catchpoint::re_set every sub-class of breakpoint now implements the
::re_set method, and if new sub-classes are added in the future I
think that they _must_ implement ::re_set in order to avoid this
problem. As such falling back to an empty breakpoint::re_set doesn't
seem helpful.
For testing I have not relied on stopping in libc and having libc
debug information available, this doesn't seem like a good idea for
the GDB testsuite. Instead I create a (rather pointless) condition
check that uses a type defined only within a shared library. When the
inferior is restarted the catchpoint will temporarily be marked as
disabled_by_cond (due to the type not being available), but once the
shared library is loaded again the catchpoint will be re-enabled.
Without the fixes above then the same crashing behaviour can be
observed.
One point of note: the dangling pointer of course exposes undefined
behaviour, with no guarantee of a crash. Though a crash is what I
usually see I have see GDB throw random errors from the expression
evaluation code, and once, I saw no problem at all! If you recompile
GDB with the address sanitizer, or run under valgrind, then the bug
will be exposed every time.
After fixing this bug I checked bugzilla and found PR gdb/29960 which
is the same bug. I was able to reproduce the bug before this commit,
and after this commit GDB is no longer crashing.
Before:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) run
Starting program: /tmp/hello.x
Hello World
[Inferior 1 (process 1101855) exited normally]
(gdb) catch syscall 1
Catchpoint 1 (syscall 'write' [1])
(gdb) condition 1 write.fd == 1
(gdb) run
Starting program: /tmp/hello.x
Fatal signal: Segmentation fault
...
And after:
(gdb) file /tmp/hello.x
Reading symbols from /tmp/hello.x...
(gdb) run
Starting program: /tmp/hello.x
Hello World
Args: ( 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 )
[Inferior 1 (process 1102373) exited normally]
(gdb) catch syscall 1
Catchpoint 1 (syscall 'write' [1])
(gdb) condition 1 write.fd == 1
(gdb) r
Starting program: /tmp/hello.x
Error in testing condition for breakpoint 1:
Attempt to extract a component of a value that is not a structure.
Catchpoint 1 (call to syscall write), 0x00007ffff7eb94a7 in write ()
from /lib64/libc.so.6
(gdb) ptype write
type = <unknown return type> ()
(gdb)
Notice we get the error now when the condition fails to evaluate.
This seems reasonable given that 'write' will be a function, and
indeed the final 'ptype' shows that it's a function, not a struct.
Tom de Vries [Wed, 4 Sep 2024 13:37:28 +0000 (15:37 +0200)]
[gdb/testsuite] Fix gdb.arch/riscv-tdesc-regs.exp
On riscv64-linux, with test-case gdb.arch/riscv-tdesc-regs.exp I get:
...
(gdb) info registers fflags^M
fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0^M
(gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers fflags
info registers frm^M
frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]^M
(gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers frm
...
The FAILs are produced by:
...
foreach reg {fflags frm} {
gdb_test_multiple "info registers $reg" "" {
-re "^info registers $reg\r\n" {
exp_continue
}
Christophe Lyon [Wed, 19 Jun 2024 12:35:30 +0000 (12:35 +0000)]
arm: Do not insert stubs needing Arm code on Thumb-only cores.
We recently fixed a bug in libgcc
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360)
where a symbol was missing a %function .type decoration.
This meant the linker would silently pick the wrong type of 'farcall
stub', involving Arm-mode instructions on Thumb-only CPUs.
This patch emits an error instead, and warns in some other cases, to
encourage users to add the missing '.type foo,%function' directive.
In practice: in arm_type_of_stub() we no longer try to infer which
stub to use if the destination is of unknown type and the CPU is
Thumb-only; so we won't lie to elf32_arm_size_stubs() which does not
check branch_type.
If branch_type is ST_BRANCH_TO_ARM but the CPU is Thumb-only, we now
convert it to ST_BRANCH_TO_THUMB only if the destination is of
absolute type. This is to support the case where the destination of
the branch is defined by the linker script (see thumb-b-lks-sym.s and
thumb-bl-lks-sym.s testcases for instance).
The motivating case is covered by the new farcall-missing-type
testcase, where we now emit an error message. We do not emit an error
when branch_type is ST_BRANCH_UNKNOWN and the CPU supports Arm-mode: a
lot of legacy code (e.g. newlib's crt0.S) lacks the corresponding
'.type foo, %function' directives and even a (too verbose) warning
could be perceived as a nuisance.
Existing testcases where such a warning would trigger:
arm-static-app.s (app_func, app_func2)
arm-rel32.s (foo)
arm-app.s (app_func)
rel32-reject.s () main)
fix-arm1176.s (func_to_branch_to)
but this list is not exhaustive.
For the sake of clarity, the patch replaces occurrences of
sym.st_target_internal = 0; with
sym.st_target_internal = ST_BRANCH_TO_ARM;
enum arm_st_branch_type is defined in include/elf/arm.h, and relies on
ST_BRANCH_TO_ARM==0, as sym.st_target_internal is also initialized to
0 in other target-independent parts of BFD code. (For instance,
swapping the ST_BRANCH_TO_ARM and ST_BRANCH_TO_THUMB entries in the
enum definition leads to 'interesting' results...)
Regarding the testsuite:
* new expected warning for thumb-b-lks-sym and thumb-bl-lks-sym
* new testcase farcall-missing-type to check the new error case
* attr-merge-arch-2b.s, branch-futures (and bfs-1.s) updated to avoid
a diagnostic
This script is a copy of the current script used by Sourceware's
autoregen buildbots.
It is intended as a helper to regenerate files managed by autotools
(autoconf, automake, aclocal, ....), as well as the toplevel
Makefile.in which is created by autogen.
Other files can be updated when using maintainer-mode, but this is not
covered by this script.
So, how does this happen? In short:
- skip_prologue_sal calls arm_skip_prologue with pc == 0x4ec,
- thumb_analyze_prologue returns 0x4f2
(overshooting by 1 insn, PR tdep/31981), and
- skip_prologue_sal decides that we're mid-line, and updates to 0x4f6.
However, this is a test-case about .debug_line info, so why didn't arm_skip_prologue
use the line info to skip the prologue?
The answer is that the line info starts at bar_label, not at bar.
Fixing that allows us to work around PR tdep/31981.
Likewise in gdb.dwarf2/dw2-line-number-zero.exp.
Instead, add a new test-case gdb.arch/skip-prologue.exp that is dedicated to
checking quality of architecture-specific prologue analysis, without being
written in an architecture-specific way.
If fails on arm-linux for both marm and mthumb:
...
FAIL: gdb.arch/skip-prologue.exp: f2: $bp_addr == $prologue_end_addr (skipped too much)
FAIL: gdb.arch/skip-prologue.exp: f4: $bp_addr == $prologue_end_addr (skipped too much)
...
and passes for:
- x86_64-linux for {m64,m32}x{-fno-PIE/-no-pie,-fPIE/-pie}
- aarch64-linux.
Mark Harmstone [Sun, 1 Sep 2024 16:42:30 +0000 (17:42 +0100)]
bfd/pdb: fix bitmap generation in pdb_write_bitmap
MSVC 2022 is more pedantic than MSVC 2019 when it comes to loading PDB
files in readonly mode, and was rejecting PDB files generated by binutils
because of their invalid free-space bitmaps. It's unknown what would
have happened if you tried to use MS tools to modify a PDB created by
binutils, but it probably would have led to a corrupted file.
This patch fixes pdb_write_bitmap so we generate files that MSVC will accept.
Specifically there were three things we were doing wrong:
- We weren't including the superblock (block 0)
- We were setting bits in bytes backwards (MSB to LSB, rather than LSB to MSB)
- We should have been marking the contents of stream 0 as free. This is
because, as the comment says, it's intended to be used for the
directory for the previous write, to allow atomic updates.
gas/ChangeLog:
* NEWS: Updated.
* config/tc-riscv.c (validate_riscv_insn): Add custom operands.
(riscv_ip): Likewise.
* doc/c-riscv.texi: Note XCVsimd as an additional ISA extension
for CORE-V.
* testsuite/gas/riscv/march-help.l: Add xcvsimd.
* testsuite/gas/riscv/x-cv-simd.d: New test.
* testsuite/gas/riscv/x-cv-simd.s: New test.
* testsuite/gas/riscv/x-cv-simd-fail.d: New test.
* testsuite/gas/riscv/x-cv-simd-fail.l: New test.
* testsuite/gas/riscv/x-cv-simd-fail.s: New test.
include/ChangeLog:
* opcode/riscv-opc.h: Add corresponding MATCH and MASK macros
for XCVsimd.
* opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros
for XCVsimd.
(enum riscv_insn_class): Add the XCVsimd instruction class.
In the patch, in order to support ymm rounding for AVX10.2, we derive
evex attribute for all cases instead of only for rc_none to encode U bit.
Also changed some bad_opcode return due to the share of U bit with APX_F.
gas/ChangeLog:
* config/tc-i386.c
(cpu_flags_match): Handle AVX10_2.
(build_evex_prefix): Handle U bit. Derive evex attribute
for all cases.
(check_VecOperands): Handle AVX10.2 and ymm roundings.
* doc/c-i386.texi: Document .avx10.2.
* testsuite/gas/i386/i386.exp: Run AVX10.2 tests.
* testsuite/gas/i386/x86-64.exp: Ditto.
* testsuite/gas/i386/avx10_2-rounding-intel.d: New test.
* testsuite/gas/i386/avx10_2-rounding-inval.l: Ditto.
* testsuite/gas/i386/avx10_2-rounding-inval.s: Ditto.
* testsuite/gas/i386/avx10_2-rounding.d: Ditto.
* testsuite/gas/i386/avx10_2-rounding.s: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-rounding.d: Ditto.
* testsuite/gas/i386/x86-64-avx10_2-rounding.s: Ditto.
opcodes/ChangeLog:
* i386-dis.c (struct instr_info): Add U bit.
(get_valid_dis386): Handle U bit.
* i386-gen.c (isa_dependencies): Add AVX10.2.
(cpu_flags): Ditto.
* i386-init.h: Regenerated.
* i386-opc.h (CpuAVX10_2): New.
(i386_cpu_flags): Add cpuavx10_2.
* i386-opc.tbl: Add rounding to old entries which do not
permit rounding previously. Also eliminate the redundant
RegXMM for vcvtps2uqq.
* i386-tbl.h: Regenerated.
R_386_TLS_DESC_CALL and R_X86_64_TLSDESC_CALL are used only in
call *x@tlscall(%[er]ax)
* elf32-i386.c (elf_i386_check_tls_transition): Use foo@indntpoff
in comments for R_386_TLS_IE check.
(elf_i386_tls_transition): Use @tlscall in comments for
R_386_TLS_DESC_CALL check.
* elf64-x86-64.c (elf_x86_64_tls_transition): Use @tlscall in
comments for R_X86_64_TLSDESC_CALL check.
H.J. Lu [Wed, 21 Aug 2024 15:06:41 +0000 (08:06 -0700)]
gold: Always resolve non-default weak undefined to 0
Non-default weak undefined symbols in executable and shared library are
always resolved to 0 at runtime and don't need dynamic relocation.
Tested on i686, x86-64, powerpc64le and aarch64.
PR gold/32071
* symtab.cc (Symbol::final_value_is_known): Always resolve
non-default weak undefined symbol in executable and shared library
to 0 at runtime.
* symtab.h (Symbol::needs_dynamic_reloc): Return false for
non-default weak undefined symbol in executable and shared library.
* testsuite/Makefile.am: Add weak_undef_test_3 and
weak_undef_test_4 tests.
* testsuite/Makefile.in: Regenerated.
* testsuite/weak_undef_lib_4.c: New file.
* testsuite/weak_undef_test_3.c: Likewise.
* testsuite/weak_undef_test_4.c: Likewise.
Tom de Vries [Sat, 31 Aug 2024 05:56:48 +0000 (07:56 +0200)]
[gdb/testsuite] Handle unsupported catch syscall
On riscv64-linux, I run into:
...
Expecting: ^(catch syscall[^M
]+)?((&.*)*.*~"Catchpoint 5 .*\\n".*=breakpoint-created,bkpt=\{number="5",type="catchpoint".*\}.*\n\^done[^M
]+[(]gdb[)] ^M
[ ]*)
catch syscall^M
&"catch syscall\n"^M
&"The feature 'catch syscall' is not supported on this architecture yet.\n"^M
^error,msg="The feature 'catch syscall' is not supported on this architecture yet."^M
(gdb) ^M
FAIL: gdb.mi/mi-breakpoint-changed.exp: test_insert_delete_modify: catch syscall (unexpected output)
...
Fix this by:
- factoring out proc supports_catch_syscall out of gdb.base/catch-syscall.exp,
and
- using it in gdb.mi/mi-breakpoint-changed.exp.
Tom Tromey [Wed, 28 Aug 2024 13:33:46 +0000 (07:33 -0600)]
Fix regexp quoting in gdb.ada test cases
I noticed that some gdb.ada tests used regular expressions like:
"Continuing\..*$inferior_exited_re.*" \
Here, the "\." should either be "." or "\\." -- "\." is not really
meaningful.
This patch fixes all the cases of this I could find in gdb.ada. In
one test (fun_renaming.exp), using "\\." would result in failures, and
here I rewrote the tests to use -wrap.
Jan Beulich [Fri, 30 Aug 2024 09:23:16 +0000 (11:23 +0200)]
x86: limit RegRex64 use
The special property really only applies to the "extended" byte regs
having legacy word/dword counterparts.
While touching involved code also drop redundant byte checks from a
conditional in establish_rex(): The other remaining RegRex64 uses only
exist on registers which can't be used as register operands anyway.
Hence RegRex64 as an attribute of a (valid) register operand implies
that it's a byte reg.
Jan Beulich [Fri, 30 Aug 2024 09:22:41 +0000 (11:22 +0200)]
gas: properly check for ELF in LISTING_NODEBUG handling
While OBJ_MAYBE_ELF presently implies OBJ_ELF (due to obj-multi.h
including obj-elf.h for obscure reasons), there still need to be IS_ELF
checks to cover for the OBJ_MAYBE_ELF case. Note, however, that code
checking for ->debugging being true doesn't need such extra checks, as
the field can only ever be true when IS_ELF.
On the same basis reduce #ifdef-ary in debugging_pseudo().
Also move the field (into what on 64-bit architectures is a 32-bit gap)
and put it inside an OBJ_ELF conditional, too.
While there further switch int to bool in related code.
Jan Beulich [Fri, 30 Aug 2024 09:21:58 +0000 (11:21 +0200)]
gas: generated code/data listing output vs .endr and alike
These ending directives are swallowed by buffer_and_nest() and hence
aren't seen by read_a_source_file(). Thus they also weren't announced to
the listing subsystem. That was, when macro expansions are included,
thus misguided to associate possible output resulting from the first
line of the construct being expanded with both the .endr and that first
line (i.e. showing it twice).
... where kernel is a function compiled to execute on the GPU. It does
not exist in the host x86-64 program that runs the main function, and
GDB doesn't know about that function until it is called, at which point
the runtime loads the corresponding code object and GDB learns about the
code of the "kernel" function. Before the GPU code object is loaded,
from the point of view of GDB, you might as well have blank lines
instead of the "kernel" function. The DWARF in the host program doesn't
describe anything at these lines.
So, a common problem that users face is:
- Start GDB with the host binary
- Place a breakpoint by line number at the "break here" line
- At this point, GDB only knows about the host code, the lines of the
`kernel` function are a big void.
- GDB finds no code mapped to the "break here" line and searches for
the first following line that has code mapped to it.
- GDB finds that the line with the opening bracket of the `main`
function (or around there) has code mapped to it, places breakpoint
there.
- User runs the program.
- The programs hits the breakpoint at the start of main.
- User is confused, because they didn't ask for a breakpoint in main.
If they continue, the code object eventually gets loaded, GDB reads the
debug info from it, re-evaluates the breakpoint locations, and at this
point the breakpoint is placed at the expected location.
The goal of this patch is to get rid of this annoyance.
A case similar to the one shown above can actually be simulated without
GPU-specific code: using a single source file to generate a library and
an executable loading that library (see the new test
gdb.linespec/line-breakpoint-outside-function.c for an example). Before
the library is loaded, trying to place a breakpoint in the library code
results in the breakpoint "drifting" down to the main function.
To address this problem, make it so that when a user requests a
breakpoint outside a function, GDB makes a pending breakpoint, rather
than placing a breakpoint at the next line with code, which happens to
be in the next function. When the GPU kernel or shared library gets
loaded, the breakpoint resolves to a location in the kernel or library.
Note that we still want breakpoints placed inside a function to
"drift" down to the next line with code. For example, here:
9
10 void foo()
11 {
12 int x;
13
14 x++;
There is probably no code associated to lines 10, 12 and 13, but the
user can still reasonably expect to be able to put a breakpoint there.
In my experience, GCC maps the function prologue to the line with the
opening curly bracket, so the user will be able to place a breakpoint
there anyway (line 11 in the example). But I don't really see a use
case to put a breakpoint above line 10 and expect to get a breakpoint in
foo. So I think that is a reasonable behavior change for GDB.
This is implemented using the following heuristic:
- If a breakpoint is requested at line L but there is no code mapped to
L, search for a following line with associated code (this already
exists today).
- However, if:
1. the found location falls in a function symbol's block
2. the found location's address is equal the entry PC of that
function
3. the found location's line is greater that the requested line
... then we don't place a breakpoint at the found location, we will
end up with a pending breakpoint.
Change the message "No line X in file..." to "No compiled code for line
X in file...". There is clearly a line 9 in the example above, so it
would be weird to say "No line 9 in file...". What we mean is that
there is no code associated to line 9.
All the regressions that I found this patch to cause were:
1. tests specifically this behavior where placing a breakpoint before
a function results in a breakpoint on that function, in which case I
removed the tests or changed them to expect a pending breakpoint
2. linespec tests expecting things like "break -line N garbage" to
error out because of the following garbage, but we now got a
different error because line N now doesn't resolve to something
anymore. For example, before:
(gdb) break -line 3 if foofoofoo == 1
No symbol "foofoofoo" in current context.
became
(gdb) break -line 3 if foofoofoo == 1
No line 3 in the current file.
These tests were modified to refer to a valid line with code, so
that we can still test what we intended to test.
Notes:
- The CUDA compiler "solves" this problem by adding dummy function
symbols between functions, that are never called. So when you try to
insert a breakpoint in the not-yet-loaded kernel, the breakpoint
still drifts, but is placed on some dummy symbol. For reasons that
would be too long to explain here, the ROCm compiler does not do
that, and it is not a desirable option.
- You can have constructs like this:
void host_function()
{
struct foo
{
static void __global__ kernel ()
{
// Place breakpoint here
}
};
// Host code that calls `kernel`
}
The heuristic won't work then, as the breakpoint will drift somewhere
inside the enclosing function, but won't be at the start of that
function. So a bogus breakpoint location will be created on the host
side. I don't think that people are going to use this kind of
construct often though, so we can probably ignore it (or at least it
shouldn't prevent making the more common case better).
ROCm doesn't support passing a lambda kernel function to
hipLaunchKernelGGL (the function used to launch kernels on the
device), but if it eventually does, there will be the same
problem.
I think that to properly support this, we will need some DWARF
improvements to be able to say "there is really nothing at these
lines" in the line table.
Co-Authored-By: Simon Marchi <simon.marchi@efficios.com>
Change-Id: I3cc12cfa823dc7d8e24dd4d35bced8e8baf7f9b6
gdb: add GDB side target_ops::fileio_stat implementation
I managed to place a NEWS entry in the wrong place. I put the entry
in 'Changes in GDB 15' rather than 'Changes since GDB 15'. This
commit moves the entry to the correct place.
Simon Marchi [Thu, 29 Aug 2024 16:07:32 +0000 (12:07 -0400)]
gdb: include gdbsupport/gdb_obstack.h in addrmap.h
This header file uses auto_obstack, found in gdbsupport/gdb_obstack.h.
This fixes an error shown when editing addrmap.h with clangd, and makes
it so addrmap.h includes what it uses.
Alan Modra [Wed, 28 Aug 2024 12:07:13 +0000 (21:37 +0930)]
get_type_abbrev_from_form tidy
* dwarf.c (get_type_abbrev_from_form): Make uvalue param a
uint64_t. Localise variables. Don't bother clearing *data_return
and *addrev_num_return for a NULL return value.
Alan Modra [Thu, 29 Aug 2024 02:30:17 +0000 (12:00 +0930)]
ld testsuite output files
In many cases the output of one run_cc_link_tests test is used as
input for another test. I hit a case where some system change caused
errors when compiling object files, but the old .so output from a
previous test run was still there, and then was used in following
tests.
Tom de Vries [Thu, 29 Aug 2024 05:31:12 +0000 (07:31 +0200)]
[gdb/testsuite] Fix regexp in gdb.arch/i386-disp-step-self-call.exp
Usually, with test-case gdb.arch/i386-disp-step-self-call.exp I get:
...
(gdb) x/1wx 0xffffc4f8^M
0xffffc4f8: 0x08048472^M
(gdb) PASS: $exp: check return address was updated correctly
...
but sometimes I run into:
...
(gdb) x/1wx 0xffffc5c8^M
0xffffc5c8: 0x0804917e^M
(gdb) FAIL: $exp: check return address was updated correctly
...
The problem is that here:
...
set next_insn_addr 0x[format %08X $next_insn_addr]
gdb_test "x/1wx 0x[format %x $sp]" "$hex:\\s+$next_insn_addr" \
"check return address was updated correctly"
...
we're trying to match string 0x0804917e against regexp 0x0804917E due to using
"%08X" as format string.
We only run into this problem if the address contains letters, which apparently
usually isn't the case.
Fix this by using "%08x" instead as format string.
Likewise in test-case gdb.arch/amd64-disp-step-self-call.exp.
Tom Tromey [Mon, 26 Aug 2024 18:12:57 +0000 (12:12 -0600)]
Don't check dwarf2_name in process_enumeration_scope
I noticed that process_enumeration_scope checks the result of
dwarf2_name. However, this isn't needed, because new_symbol does the
same check. This patch removes the unnecessary code.
Jiaying Song [Tue, 13 Aug 2024 02:31:21 +0000 (10:31 +0800)]
dlltool: file name too long
During the execution of the command: i686-w64-mingw32-dlltool
--input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe
An error occurred:
i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_plugin_api_a_h.s
Due to the path length exceeding the Linux system's file name length
limit (NAME_MAX=255), the temporary file name generated by the
i686-w64-mingw32-dlltool command becomes too long to open. To address
this, a new temporary file name prefix is generated using tmp_prefix =
prefix_encode ("d", getpid()), ensuring that the file name does not
exceed the system's length limit.
Signed-off-by: Jiaying Song <jiaying.song.cn@windriver.com> Reviewed-by: Alan Modra <amodra@gmail.com>
use asm statement, instead of symver attribute, for GCC 9 and older.
PR gold/31830
* testsuite/ver_test_pr31830_b.c (__collector_foo_2_2): Use asm
statement, instead of symver attribute, for GCC 9 and older.
symver attribute with __asm__.
* testsuite/ver_test_pr31830_lto.c (__collector_foo_2_2): Likewise.
H.J. Lu [Sun, 25 Aug 2024 15:16:38 +0000 (08:16 -0700)]
gold: Remove duplicated rules for ifuncmain[12457]picstatic
When HAVE_STATIC and IFUNC_STATIC both are false, "make" reports:
Makefile:3796: warning: overriding recipe for target 'ifuncmain1picstatic'
Makefile:3788: warning: ignoring old recipe for target 'ifuncmain1picstatic'
Makefile:3900: warning: overriding recipe for target 'ifuncmain2picstatic'
Makefile:3892: warning: ignoring old recipe for target 'ifuncmain2picstatic'
Makefile:3932: warning: overriding recipe for target 'ifuncmain4picstatic'
Makefile:3924: warning: ignoring old recipe for target 'ifuncmain4picstatic'
Makefile:3972: warning: overriding recipe for target 'ifuncmain5picstatic'
Makefile:3964: warning: ignoring old recipe for target 'ifuncmain5picstatic'
Makefile:4048: warning: overriding recipe for target 'ifuncmain7picstatic'
Makefile:4040: warning: ignoring old recipe for target 'ifuncmain7picstatic'
due to duplicated rules for ifuncmain[12457]picstatic:
Guinevere Larsen [Tue, 27 Aug 2024 11:12:00 +0000 (08:12 -0300)]
gdb/testsuite: fix gdb.btrace/non-stop.exp end of history check
The recent commit 089197010993b3a5dc50bf882470bab2de696d92 changed the
warnings when GDB reaches the end of the recorded history, and updated
tests to expect the new messages. The pattern used for
gdb.btrace/non-stop.exp, however, was too broad and could cause the
following test result:
...
(gdb) PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: prompt
^M
Reached end of recorded history; stopping.^M
Following forward execution will be added to history.^M
test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M
30 return arg; /* bp.2 */^M
^M
Reached end of recorded history; stopping.^M
Following forward execution will be added to history.^M
test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M
30 return arg; /* bp.2 */^M
PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 0
FAIL: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 1 (timeout)
...
This happens because the pattern looks like one of these 2:
"Reached end of recorded.*Backwards execution.*"
"Reached end of recorded.*Following forward.*"
What seems to have happened is that all the output came at once, and
most of it was consumed by the first '.*' pattern when checking for
thread 0, so there was no output left for checking thread 1. This commit
fixes that by making the expected outputs more exact.
I also fixed the whitespace errors in gdb_cont_to_no_history_backwards
that pre-dated the commit above, since I was already touching that proc.
Andrew Burgess [Fri, 16 Aug 2024 11:01:54 +0000 (12:01 +0100)]
gdb/testsuite: add no-delete-breakpoints option to 'runto' proc
New 'no-delete-breakpoints' option for the 'runto' proc. This option
disables the delete_breakpoints call early on in this proc.
There are a couple of places in the testsuite where I have used:
proc no_delete_breakpoints {} {}
with_override delete_breakpoints no_delete_breakpoints {
if {![runto_main]} {
return
}
}
In order to avoid the deleting all breakpoints when I call
runto_main. I was about to add yet another instance of this pattern
and I figured that it's time to do this properly.
This commit adds the new option to 'runto' which causes the
delete_breakpoints call to be skipped.
And, we now forward any arguments from 'runto_main' through to
'runto', this means I can now just do:
if {![runto_main no-delete-breakpoints]} {
return
}
which I think is cleaner and easier to understand.
I've updated the two tests I found that use the old with_override
approach.
There should be no change in what is tested after this commit.
Andrew Burgess [Thu, 18 Jul 2024 10:16:13 +0000 (11:16 +0100)]
gdb: add 'maint info blocks' command
While reviewing a patch I wanted to understand which blocks existed at
a given address.
The 'maint print symbols' command does provide some of this
information, but that command displays all blocks within a given
symtab. If I want to know which blocks are at a given address I have
to figure that out for myself based on the output of 'maint print
symbols' ... and I'm too lazy for that!
So this command lists just those blocks at a given address, along with
information about the blocks type. This new command doesn't list the
symbols within each block, for that my expectation is that you'd cross
reference the output with that of 'maint print symbols'.
The new command format is:
maintenance info blocks
maintenance info blocks ADDRESS
This lists the blocks at ADDRESS, or at the current $pc if ADDRESS is
not given. Blocks are listed starting at the global block, then the
static block, and then the progressively narrower scoped blocks.
For each block we list the internal block pointer (which allows easy
cross referencing with 'maint print symbols'), the inferior address
range, along with other useful information.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
Andrew Burgess [Wed, 31 Jul 2024 06:42:56 +0000 (07:42 +0100)]
gdb: Add 'maint info inline-frames' command
While reviewing a patch I wanted to view GDB's inline frame state. I
don't believe there's currently a maintenance command to view this
information, so in this commit I've added one.
The new command is:
maintenance info inline-frames
maintenance info inline-frames ADDRESS
The command lists the inline frames that start at ADDRESS, or at the
current $pc if no ADDRESS is given. The command also displays the
"outer" function in which the inline functions are present.
An example of the command output:
(gdb) maintenance info inline-frames
Cached inline state information for thread 1.
program counter = 0x401137
skipped frames = 1
bar
> foo
main
(gdb)
This tells us that function 'main' called 'foo' which called 'bar'.
The functions 'foo' and 'bar' are both inline and both start at the
address 0x401137. Currently GDB considers the inferior to be stopped
in frame 'foo' (note the '>' marker), this means that there is 1
skipped frame (function 'bar').
The function 'main' is the outer function. The outer function might
not start at 0x401137, it is simply the function that contains the
inline functions.
If the user does a 'step' then GDB will not actually move the inferior
forward, but will instead simply tell the user that the inferior
entered 'bar'. The output of 'maint info inline-frames' will change
like this:
(gdb) step
bar () at inline.c:6
6 ++global_counter;
(gdb) maintenance info inline-frames
Cached inline state information for thread 1.
program counter = 0x401137
skipped frames = 0
> bar
foo
main
(gdb)
Now GDB is in function 'bar' and there are no skipped frames.
I have renamed skipped_symbols to function symbols within the
inline_state class. We are now going to carry the "outer"
function (the function that contains all the inlined functions) within
this list (as the last entry), so the old name didn't really make
sense. As a consequence of this rename I've updated some comments.
I've changed stopped_by_user_bp_inline_frame to take a symbol rather
than a block. Previously we just used the block to access the
associated function symbol. After this commit we can just pass in the
function symbol directly, so lets do that.
New function gather_inline_frames contains some of the logic pulled
from skip_inline_frames. This new function builds the list of all
symbols of inlined functions that start at a given $pc value and also
the "outer" function that contains all of the inlined functions.
In skip_inline_frames I've split the loop logic into two. The loop to
build the function symbol list has moved to gather_inline_frames. The
loop to figure out how many of the inlined functions we are skipping
remains in skip_inline_frames and uses the result of calling
gather_inline_frames.
In inline_skipped_symbol there are some minor updates to the comment,
and I've tweaked one of the asserts now that the function symbols list
also contains the "outer" function (a <= becomes <).
The maintenance_info_inline_frames function is now and implements the
new maintenance command.
And _initialize_inline_frame is updated to register the new command.
I've added a basic test for the new command. Please excuse the file
name for the new test, in the next commit I'll be adding additional
tests and at that point the file name will make sense.
Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Simon Marchi <simon.marchi@efficios.com>
H.J. Lu [Tue, 27 Aug 2024 16:48:21 +0000 (09:48 -0700)]
x86: Report invalid TLS relocation name
Get TLS relocation name from its lex_got entry when reporting invalid
instructions with TLS relocations.
PR gas/28595
* config/tc-i386.c (gotrel): Moved from ...
(lex_got): There.
(i386_assemble): Get invalid TLS relocation name from its lex_got
entry when reporting TLS relocation error.
Tom de Vries [Tue, 27 Aug 2024 09:49:34 +0000 (11:49 +0200)]
[gdb/testsuite] Fix regexp in gdb.dwarf2/dw2-inter-cu-error.exp
In commit b5070480d74 ("[gdb/symtab] Change DWARF_ERROR from Dwarf Error to
DWARF Error") I changed the dwarf error prefix, but failed to update test-case
gdb.dwarf2/dw2-inter-cu-error.exp.
Fix this by updating the corresponding regexp in the test-case.
Tom de Vries [Tue, 27 Aug 2024 07:08:41 +0000 (09:08 +0200)]
[gdb/symtab] Change DWARF_ERROR from Dwarf Error to DWARF Error
It was suggested here [1] that the canonical prefix for dwarf errors
should not be "Dwarf Error: ", given that the canonical spelling is DWARF
instead of Dwarf.
Fix this by using "DWARF Error: " instead.
Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single
location.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com> Approved-By: Tom Tromey <tom@tromey.com>
[1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html
Tom de Vries [Tue, 27 Aug 2024 07:08:41 +0000 (09:08 +0200)]
[gdb/symtab] Use [in module %s] notation more consistently in dwarf errors
In gdb/dwarf2/read.c, I found a few strings "in module %s":
...
$ grep "in module %s" gdb/dwarf2/read.c | fgrep -v '['
"DIE at %s in module %s"),
error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
error (_("Dwarf Error: DIE at %s referenced in module %s "
error (_("Dwarf Error: Dummy CU at %s referenced in module %s"),
error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"),
...
that are not using the commonly used "[in module %s]" notation. Fix these.
In one case, the string was also used in the middle rather than at the end of
the message, so fix that as well.
Jiawei [Tue, 20 Aug 2024 02:10:21 +0000 (10:10 +0800)]
RISC-V: PR32036, Support Zcmp cm.mva01s and cm.mvsa01 instructions.
This patch supports Zcmp instruction 'cm.mva01s' and 'cm.mvsa01'.
All disassemble instructions use the sreg format.
Co-Authored by: Charlie Keaney <charlie.keaney@embecosm.com>
Co-Authored by: Mary Bennett <mary.bennett@embecosm.com>
Co-Authored by: Nandni Jamnadas <nandni.jamnadas@embecosm.com>
Co-Authored by: Sinan Lin <sinan.lin@linux.alibaba.com>
Co-Authored by: Simon Cook <simon.cook@embecosm.com>
Co-Authored by: Shihua Liao <shihua@iscas.ac.cn>
Co-Authored by: Yulong Shi <yulong@iscas.ac.cn>
gas/ChangeLog:
PR 32036
* NEWS: Updated.
* config/tc-riscv.c (validate_riscv_insn): New operators.
(riscv_ip): Ditto.
* testsuite/gas/riscv/zcmp-mv.d: New test.
* testsuite/gas/riscv/zcmp-mv.s: New test.
include/ChangeLog:
PR 32036
* opcode/riscv-opc.h (MATCH_CM_MVA01S): New opcode.
(MASK_CM_MVA01S): New mask.
(MATCH_CM_MVSA01): New opcode.
(MASK_CM_MVSA01): New mask.
(DECLARE_INSN): New declarations.
* opcode/riscv.h (OP_MASK_SREG1): New mask.
(OP_SH_SREG1): New operand code.
(OP_MASK_SREG2): New mask.
(OP_SH_SREG2): New operand code.
(X_A0): New reg number.
(X_A1): Ditto.
(X_S7): Ditto.
(RISCV_SREG_0_7): New macro function.
opcodes/ChangeLog:
PR 32036
* riscv-dis.c (riscv_zcmp_get_sregno): New function.
(print_insn_args): New operators.
* riscv-opc.c (match_sreg1_not_eq_sreg2): New match function.
Tom Tromey [Mon, 26 Aug 2024 19:29:04 +0000 (13:29 -0600)]
Simplify ada_identical_enum_types_p
This patch changes ada_identical_enum_types_p to reuse the field names
that are computed earlier in the loop. This is a simple cleanup, but
also is useful for a larger change that I'm working on.
Mark Harmstone [Mon, 26 Aug 2024 12:58:56 +0000 (13:58 +0100)]
ld/PDB: handle pointers to members
If the CV_PTR_MODE_PMEM or CV_PTR_MODE_PMFUNC flags were set in an
LF_POINTER entry's attributes, there's a few extra bytes on the end that
we weren't accounting for.
Change handle_type so that we remap the containing_class field if it's
present, and add a test for this.
William Ferreira [Thu, 18 Jul 2024 19:38:31 +0000 (16:38 -0300)]
gdb: imply --once if connecting via stdio
Currently, gdbserver hangs after stdin is closed while it tries to
write: "Remote side has terminated connection. GDBserver will reopen
the connection." This hang disappears if --once is also given. Since
the stdin connection won't ever reopen if it's closed, it's safe to
assume --once is desired.
The gdb.server/server-pipe.exp test was also updated to reflect this
change. There is now a second disconnect at the end of the proc,
with a tighter-than-normal timeout to catch if the command hangs as
it used to.
Guinevere Larsen [Mon, 26 Aug 2024 13:33:17 +0000 (10:33 -0300)]
Change message when reaching end of reverse history.
In a record session, when we move backward, GDB switches from normal
execution to simulation. Moving forward again, the emulation continues
until the end of the reverse history. When the end is reached, the
execution stops, and a warning message is shown. This message has been
modified to indicate that the forward emulation has reached the end, but
the execution can continue as normal, and the recording will also continue.
Before this patch, the warning message shown in that case was the same as
in the reverse case. This meant that when the end of history was reached in
either backward or forward emulation, the same message was displayed:
"No more reverse-execution history."
This message has changed for these two cases. Backward emulation:
"Reached end of recorded history; stopping.
Backward execution from here not possible."
Forward emulation:
"Reached end of recorded history; stopping.
Following forward execution will be added to history."
The reason for this change is that the initial message was deceiving, for
the forward case, making the user believe that forward debugging could not
continue.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31224 Reviewed-By: Markus T. Metzger <markus.t.metzger@intel.com> (btrace) Approved-By: Guinevere Larsen <blarsen@redhat.com>
Lulu Cai [Fri, 9 Aug 2024 09:40:59 +0000 (17:40 +0800)]
LoongArch: Fix wrong relocation handling of symbols defined by PROVIDE
If the symbol defined by PROVIDE in the link script is not in SECTION,
the symbol is placed in the ABS section. The linker considers that
symbols in the ABS section do not need to calculate PC relative offsets.
Symbols in ABS sections should calculate PC relative offsets normally
based on relocations.
Alan Modra [Sun, 25 Aug 2024 05:50:21 +0000 (15:20 +0930)]
PR32109, aborting at bfd/bfd.c:1236 in int _bfd_doprnt
Since bfd_section for .strtab isn't set, print the section index
instead. Also, don't return NULL on this error as that results in
multiple mmap/read of the string table. (We could return NULL if we
arranged to set sh_size zero first, but just what we do with fuzzed
object files is of no concern, and terminating the table might make a
faulty object file usable.)
PR 32109
* elf.c (bfd_elf_get_str_section): Remove outdated comment, and
tweak shstrtabsize test to suit. Don't use string tab bfd_section
in error message, use index instead. Don't return NULL on
unterminated string section, terminate it.
(_bfd_elf_get_dynamic_symbols): Similarly terminate string table
section.
Aaron Merey [Wed, 13 Mar 2024 20:18:27 +0000 (16:18 -0400)]
gdb/dwarf2: Check for null abbrev_info ptr
A corrupt debuginfo file can result in a null abbrev_info pointer
being passed to cooked_indexer::scan_attributes. This pointer
is set to nullptr by peek_die_abbrev when an abbrev of 0 is found.
There is no check for whether the abbrev pointer is null and
SIGSEGV occurs when attempting to dereference the pointer.
An abbrev of 0 normally indicates that the corresponding DIE is a
null entry, but scan_attributes expects a non-null DIE.
Fix this by throwing an error in cooked_indexer::scan_attributes
when peek_die_abbrev returns a nullptr in order to avoid
scan_attributes calling itself with a null abbrev.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478 Co-authored-by: Tom de Vries <tdevries@suse.de> Approved-By: Tom Tromey <tom@tromey.com>
Jan Beulich [Fri, 23 Aug 2024 07:24:10 +0000 (09:24 +0200)]
x86: simplify SAE checking
To determine whether SAE (with or without StaticRounding) is permitted
there's no need to iterate over all operands. Even less so starting at
the front (thus needlessly inspecting immediate operands as well).
Leverage the pattern across all relevant templates and check only the
last two operands, and also only for non-512 ones (besides the non-LIG
case that was already checked for).
Jan Beulich [Fri, 23 Aug 2024 07:22:30 +0000 (09:22 +0200)]
RISC-V: process rs_align_code also when relaxing
riscv_handle_align() runs after all input was processed. Whether
relaxation is enabled for any particular piece of code is not recorded
anywhere. (This issue was even "worked around" in a gas testcase, which
is adjusted accordingly.) Furthermore, as demonstrated by an ld
testcase, tail padding in an object file's executable sections depended
on whether relaxation was enabled at the end of assembly: NOPs were
emitted only when relaxation was off; zeroes were emitted with
relaxation enabled. (It could probably be either way, but it should be
independent of relaxation state at the end of assembly. Except of course
write.c, in a comment ahead of #define-ing SUB_SEGMENT_ALIGN(),
explicitly says "proper nop-filling".)
While re-indenting, drop the "odd_padding" variable. It's used exactly
once, and having the actual expression right in the if() is imo helping
readers to understand what the intentions are.
While touching the ld testcase, also tighten the expectations for the
addresses of the two symbols: The last two digits have to have fixed
values.
Tom de Vries [Thu, 22 Aug 2024 08:00:27 +0000 (10:00 +0200)]
[gdb/symtab] Return correct reader for top-level CU in cooked_indexer::ensure_cu_exists
With the test-case included in this patch, we run into:
...
$ gdb -q -batch $exec
Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \
[in module $exec]
...
The debug info consists of two CUs:
...
Compilation Unit @ offset 0xb2:
Length: 0x25 (32-bit)
Version: 4
Abbrev Offset: 0x6c
Pointer Size: 8
<0><bd>: Abbrev Number: 1 (DW_TAG_compile_unit)
<be> DW_AT_language : 2 (non-ANSI C)
<1><bf>: Abbrev Number: 2 (DW_TAG_subprogram)
<c0> DW_AT_low_pc : 0x4004a7
<c8> DW_AT_high_pc : 0x4004b2
<d0> DW_AT_specification: <0xe8>
<1><d4>: Abbrev Number: 3 (DW_TAG_subprogram)
<d5> DW_AT_name : main
<1><da>: Abbrev Number: 0
Compilation Unit @ offset 0xdb:
Length: 0xf (32-bit)
Version: 4
Abbrev Offset: 0x86
Pointer Size: 8
<0><e6>: Abbrev Number: 1 (DW_TAG_compile_unit)
<e7> DW_AT_language : 2 (non-ANSI C)
<1><e8>: Abbrev Number: 2 (DW_TAG_subprogram)
<e9> DW_AT_specification: <0xd4>
<1><ed>: Abbrev Number: 0
...
where:
- DIE 0xbf in CU@0xb2 contains an inter-CU reference to
- DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to
- DIE 0xd4 back in CU@0xb2.
The dwarf error is caused by this bit of code in
cooked_indexer::ensure_cu_exists:
...
if (per_cu == m_per_cu)
return reader;
...
The dwarf error happens as follows:
- a cutu_reader A is created for CU@0xb2
- using cutu_reader A, the cooked index reader starts indexing dies, with
m_per_cu set to CU@0xb2
- while indexing it scans the attributes of DIE 0xbf and encounters the
inter-CU reference to DIE 0xe8
- it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for
CU@0xdb and returns it
- using cutu_reader B, it continues scanning attributes of DIE 0xe8 and
encounters the inter-CU reference to DIE 0xd4
- it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered
and cutu_reader B is returned
- using cutu_reader B, it continues scanning attributes of DIE 0xd4
- this goes wrong because:
- the attributes of the DIE are encoded using the abbreviation table at
offset 0x6c, while
- the decoding is done using cutu_reader B which uses the abbreviation table
at offset 0x86.
Fix this by removing the problematic if clause.
Since cutu_reader A is not preserved in m_index_storage,
cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate
cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving
the cutu_reader A as well in m_index_storage.
Tom de Vries [Thu, 22 Aug 2024 07:49:53 +0000 (09:49 +0200)]
[gdb/python] Eliminate catch(...) in type_to_type_object
In type_to_type_object we have:
...
try
{
if (type->is_stub ())
type = check_typedef (type);
}
catch (...)
{
/* Just ignore failures in check_typedef. */
}
...
The catch is supposed to ignore gdb_exception_error, but it ignores any
exception.
Fix that by only ignoring gdb_exception_error, and handling
gdb_exception_quit / gdb_exception_forced_quit using GDB_PY_HANDLE_EXCEPTION.
projects / thirdparty / binutils-gdb.git / log
