binutils_gdb

Fork

Automatic date update in version.in

gdb/doc: reword description of DisassembleInfo.read_memory

While reading the documentation of DisassembleInfo.read_memory I
spotted the word 'available' in one sentence where it didn't make
sense.

sim/lm32: fix some missing function declaration warnings

In the lm32 simulator, I was seeing some warnings about missing
function declarations.

The lm32 simulator has a weird header structure, in order to pull in
the full cpu.h header we need to define WANT_CPU_LM32BF. This is done
in some files, but not in others. Critically, it's not done in some
files that then use functions declared in cpu.h

In this commit I added the missing #define so that the full cpu.h can
be included.

After doing this there are still a few functions that are used
undeclared, these functions appear to be missing any declarations at
all, so I've added some to cpu.h.

With this done all the warnings when compiling lm32 are resolved for
both gcc and clang, so I've removed the SIM_WERROR_CFLAGS line from
Makefile.in, this allows lm32 to build with -Werror.

sim/h8300: avoid self assignment

There are two places in the h8300 simulator where we assign a variable
to itself. Clang gives a warning for this, which is converted into an
error by -Werror.

Silence the warning by removing the self assignments. As these
assignments were in a complex if/then/else tree, rather than try to
adjust all the conditions, I've just replaced the self assignments
with a comment and an empty statement.

sim/aarch64: remove two unused functions

These functions are not used. Clang warns about the unused functions,
which is then converted into an error by -Werror.

Delete the unused functions.

sim/ppc: fix for operator precedence warning from clang

In the ppc simulator, clang was warning about some code like this:

busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P(out_vmask)) ? 1 : 2;

The warning was:

operator '?:' has lower precedence than '+'; '+' will be evaluated first

I suspect that this is not the original authors intention.
PPC_ONE_BIT_SET_P is going to be 0 or 1, so if we evaluate the '+'
first, the condition will always be non-zero, so true. The whole
expression could then be simplified to just '1', which doesn't make
much sense.

I suspect the answer the author was expecting was either 2 or 3. Why
they didn't just write:

busy_ptr->nr_writebacks = (PPC_ONE_BIT_SET_P(out_vmask)) ? 2 : 3;

I have no clue, however, to keep the structure of the code unchanged,
I've updated things to:

busy_ptr->nr_writebacks = 1 + (PPC_ONE_BIT_SET_P (out_vmask) ? 1 : 2);

which silences the warning from clang, and is, I am guessing, what the
original author intended.

sim/ppc: initialize a memory buffer in all cases

In the ppc simulator's do_fstat function, which provides the fstat
call for the simulator, if the fstat is going to fail then we
currently write an uninitialized buffer into the simulated target.

In theory, I think this is fine, we also write the error status into
the simulated target, so, given that the fstat has failed, the target
shouldn't be relying on the buffer contents.

However, writing an uninitialized buffer means we might leak simulator
private data into the simulated target, which is probably a bad thing.
Plus it probably makes life easier if something consistent, like all
zeros, is written rather than random junk, which might look like a
successful call (except for the error code).

So, in this commit, I initialize the stat buffer to zero before
it is potentially used. If the stat call is not made then the buffer
will be left initialized as all zeros.

sim/ppc: don't try to print an uninitialized variable

The ppc simulator, in sim_create_inferior, tries to print the function
local entry_point variable before the variable is initialized.

In this commit, I defer the debug print line until the variable has
been initialized.

sim/sh: use fabs instead of abs

The sh simulator incorrectly uses integer abs instead of the floating
point fabs on some floating point values, fixed in this commit.

[gdb] Fix rethrow exception slicing in insert_bp_location

The preferred way of rethrowing an exception is by using throw without
expression, because it avoids object slicing of the exception [1].

Fix this in insert_bp_location.

Tested on x86_64-linux.

[1] https://en.cppreference.com/w/cpp/language/throw

Approved-By: Andrew Burgess <aburgess@redhat.com>

[gdb] Fix rethrow exception slicing in pretty_print_insn

The preferred way of rethrowing an exception is by using throw without
expression, because it avoids object slicing of the exception [1].

Fix this in gdb_pretty_print_disassembler::pretty_print_insn.

Tested on x86_64-linux.

[1] https://en.cppreference.com/w/cpp/language/throw

Approved-By: Andrew Burgess <aburgess@redhat.com>

ld/testsuite: adjust ld-arm to run shared tests only when supported

If a custom arm-elf target is disabling the shared support, a lot of
failures are reported by the testsuite.
Moreover, some tests try to access libraries which have been explicitly
skipped earlier (eg mixed-lib.so).

ld/ChangeLog:

* testsuite/ld-arm/arm-elf.exp: Separate tests needing shared
lib support.

ld/testsuite: skip ld-elf/exclude when -shared is not supported

ld/ChangeLog:

* testsuite/ld-elf/exclude.exp: Call check_shared_lib_support.
to skip for all targets without shared lib support.

x86: consolidate VPCLMUL tests

There's little point in having Intel syntax disassembler tests when the
purpose of a test is assembler functionality: Drop all
*avx512*_vpclmulqdq-wig1-intel.

For *avx512*_vpclmulqdq-wig1 share source with *avx512*_vpclmulqdq.

Finally put in place similar tests for -mvexwig=1.

x86: consolidate VAES tests

There's little point in having Intel syntax disassembler tests when the
purpose of a test is assembler functionality: Drop all
*avx512*_vaes-wig1-intel.

For *avx512*_vaes-wig1 share source with *avx512*_vaes. This in
particular makes sure that the 32-bit VL test actually tests any EVEX
encodings in the first place.

Finally put in place similar tests for -mvexwig=1.

x86: emit {evex} prefix when disassembling ambiguous AVX512VL insns

When no AVX512-specific functionality is in use, the disassembly of
AVX512VL insns is indistinguishable from their AVX counterparts (if such
exist). Emit the {evex} pseudo-prefix in such cases.

Where applicable drop stray uses of PREFIX_OPCODE from table entries.

[gdb/testsuite] Add skip_python_tests in gdb.python/tui-window-names.exp

I did a gdb build without python support, and during testing ran into FAILs in
test-case gdb.python/tui-window-names.exp.

Fix this by adding the missing skip_python_test.

Tested on x86_64-linux.

Automatic date update in version.in

sim: testsuite: update ignored .exp files [PR sim/29596]

Now that we run `check/foo.exp` instead of `check/./foo.exp`,
update the config/ & lib/ exceptions to cover both paths.

Bug: https://sourceware.org/PR29596

sim: testsuite: tweak parallel find invocation [PR sim/29596]

Make sure we invoke runtest with the same exp filenames when running in
parallel as it will find when run single threaded. When `runtest` finds
files itself, it will use paths like "aarch64/allinsn.exp". When we run
`find .` with the %p option, it produces "./aarch64/allinsn.exp". Switch
to %P to get "aarch64/allinsn.exp".

Bug: https://sourceware.org/PR29596

sim: mips/ppc/riscv: re-add AC_CANONICAL_SYSTEM [PR sim/29439]

These configure scripts check $target and change behavior. They
shouldn't be doing that, but until we can rework the sim to change
behavior based on the input ELF, restore AC_CANONICAL_SYSTEM to
these so that $target is correctly populated.

This was lost in the d3562f83a7b8a1ae6e333cd5561419d3da18fcb4
("sim: unify toolchain probing logic") refactor as the logic was
hoisted up to the common code. But the fact the vars weren't
passed down to the sub-configure scripts was missed.

Bug: https://sourceware.org/PR29439

Automatic date update in version.in

gdb/testsuite: add max number of instructions check in gdb.base/unwind-on-each-insn.exp

This test sends my CI in an infinite loop of failures. We expect to
have a handful of iterations (5 on my development machine, where the
test passes fine)but the log shows that it went up to 104340 iterations:

FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id
DUPLICATE: gdb.base/unwind-on-each-insn.exp - instruction 104340: maint print frame-id
FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: [string equal $fid $main_fid]
FAIL: gdb.base/unwind-on-each-insn.exp - instruction 104340: get hexadecimal valueof "$pc"

Add a max instruction check, exit the loop if we reach 100 iterations.
This should allow the test to fail fast if there's a problem, but 100
iterations should be more than enough for when things are working.

Change-Id: I77978d593aca046068f9209272d82e1675ba17c2

Automatic date update in version.in

Improve Python Unwinders documentation

- avoid "GDB proper" to refer to global locus, as object files and
program spaces are also GDB proper.

- gdb.register_unwinder does not accept locus=gdb.

- "a unwinder" -> "an unwinder"

Approved-by: Eli Zaretskii <eliz@gnu.org>
Change-Id: I98c1b1000e1063815238e945ca71ec6f37b5702e

gdb: make inherit_abstract_dies use vector iterators

Small cleanup to use std::vector iterators rather than raw pointers.

Approved-By: Tom Tromey <tom@tromey.com>
Change-Id: I8d50dbb3f2d8dad7ff94066a578d523f1f31b590

gdb: check for empty offsets vector in inherit_abstract_dies

When building GDB with clang and --enable-ubsan, I get:

UNRESOLVED: gdb.dwarf2/frame-inlined-in-outer-frame.exp: starti prompt

The cause being:

$ ./gdb --data-directory=data-directory -nx -q -readnow testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame
Reading symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame...
Expanding full symbols from testsuite/outputs/gdb.dwarf2/frame-inlined-in-outer-frame/frame-inlined-in-outer-frame...
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer

I found this to happen with ld-linux on at least Arch Linux and Ubuntu
22.04:

$ ./gdb --data-directory=data-directory -nx -q -readnow -iex "set debuginfod enabled on" /lib64/ld-linux-x86-64.so.2
Reading symbols from /lib64/ld-linux-x86-64.so.2...
Reading symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo...
Expanding full symbols from /home/simark/.cache/debuginfod_client/22bd7a2c03d8cfc05ef7092bfae5932223189bc1/debuginfo...
/home/simark/src/binutils-gdb/gdb/dwarf2/read.c:11954:47: runtime error: applying non-zero offset 8 to null pointer

The problem happens when doing this:

sect_offset *offsetp = offsets.data () + 1

When `offsets` is an empty vector, `offsets.data ()` returns nullptr.
Fix it by wrapping that in a `!offsets.empty ()` check.

Change-Id: I6d29ba2fe80ba4308f68effd9c57d4ee8d67c29f
Approved-By: Tom Tromey <tom@tromey.com>

readelf: support zstd compressed debug sections [PR 29640]

Fix incorrect .gdb_index with new DWARF scanner

PR symtab/29694 points out a regression caused by the new DWARF
scanner when the cc-with-gdb-index target board is used.

What happens here is that an older version of gdb will make an index
describing the "A" type as:

[737] A: 1 [global, type]

whereas the new gdb says:

[1008] A: 0 [global, type]

Here the old one is correct because the A in CU 0 is just a
declaration without a size:

<1><45>: Abbrev Number: 10 (DW_TAG_structure_type)
<46> DW_AT_name : A
<48> DW_AT_declaration : 1
<48> DW_AT_sibling : <0x6d>

This patch fixes the problem by introducing the idea of a "type
declaration". I think gdb still needs to recurse into these types,
searching for methods, but by marking the type itself as a
declaration, gdb can skip this type during lookups and when writing
the index.

Regression tested on x86-64 using the cc-with-gdb-index board.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29694

Fix crash in value_print_array_elements

A user noticed that gdb would crash when printing a packed array after
doing "set lang c". Packed arrays don't exist in C, but it's
occasionally useful to print things in C mode when working in a non-C
language -- this lets you see under the hood a little bit.

The bug here is that generic value printing does not handle packed
arrays at all. This patch fixes the bug by introducing a new function
to extract a value from a bit offset and width.

The new function includes a hack to avoid problems with some existing
test cases when using -fgnat-encodings=all. Cleaning up this code
looked difficult, and since "all" is effectively deprecated, I thought
it made sense to simply work around the problems.