Recently added test-case gdb.dwarf2/dw2-gas-workaround.exp:
- passes when gdb is configured using $(cd ../src; pwd)/configure, but
- fails when using ../src/configure.
Fix this by making the matching more precise:
...
- -re -wrap "$objdir.*" {
+ -re -wrap "name_for_id = $objdir/$srcfile\r\n.*" {
...
such that we only fail on the line:
...
[symtab-create] start_subfile: name = dw2-lines.c, name_for_id = \
/data/vries/gdb/leap-15-4/build/gdb/testsuite/dw2-lines.c^M
...
Reported-By: Carl Love <cel@us.ibm.com>
While working on background reading of DWARF, I came across the
DWZ-reading code. This code can query the user (via the debuginfod
support) -- something that cannot be done off the main thread.
Looking into it, I realized that this code can be run much earlier,
avoiding this problem. Digging a bit deeper, I also found a
discrepancy here between how the DWARF reader works in "readnow" mode
as compared to the normal modes.
This patch cleans this up by trying to read the DWZ file earlier, and
also by having the DWARF reader convert any exception here into a
warning. This unifies the various cases, but also makes it so that
errors do not prevent gdb from continuing on to the extent possible.
Regression tested on x86-64 Fedora 38.
I (almost) had a bug where I did:
buffer.slice (...)
but I meant:
buffer = buffer.slice (...)
The first one does nothing, it creates a new array_view but without
using it, it's useless. Mark the slice methods with [[nodiscard]]
(which is standard C++17) so that error would generate a warning.
I guess that many functions could be marked as nodiscard, essentially
function that is pure (doesn't have side-effects). But this one seems
particularly easy to mis-use.
Change-Id: Ib39a0a65a5728a3cfd68a02ae31635810baeaccb
Approved-By: Tom Tromey <tom@tromey.com>
Since "maint selftest" now runs quite a lot of tests (especially in an
all-targets build), I thought it would be useful to print a summary at
the end of what failed. So, implement that.
Print the summary before the "Ran %d unit tests, %zu failed\n" line, so
that that one remains the last line, and the gdb.gdb/unittest.exp
doesn't need to be changed.
The output looks like (if I force a failure in a test):
(gdb) maint selftest
...
Running selftest value_copy.
Running selftest xml_escape_text.
Running selftest xml_escape_text_append.
Failures:
aarch64-analyze-prologue
Ran 4134 unit tests, 1 failed
(gdb)
Change-Id: If3aaabdd6f8078d0e6e50e8d08f3e558ab85277e
Approved-By: Tom Tromey <tom@tromey.com>
First of all the respective original changes didn't deal with just 0
having such a suffix - this needs additional logic outside of
integer_constant(). Further bogus suffixes having more than two L-s
were accepted, while valid suffixes with U following the L(s) weren't.
Finally respective tests were introduced for Sparc only.
Reviewed-by: Neal Frager <neal.frager@amd.com>
Within the groups L{B,BU,H,HU,W,WU,D}, S{B,H,W,D}, FL{H,W,D,Q}, and
FS{H,W,D,Q} the sole difference between the handling is the insn
mnemonic passed to the common handling functions. The intended mnemonic,
however, can easily be retrieved. Furthermore leverags that Sx and FSx
are then handled identically, too, and hence their cases can also be
folded.
When support for the Q extension was added, the libopcodes side of these
macro-insns was properly covered, but no backing support in gas was
added. In new testcases cover not just these, but all Q-extension insns.
On AlmaLinux 9.2 powerpc64le I run into:
...
(gdb) PASS: gdb.ada/array_return.exp: continuing to Create_Small_Float_Vector
finish^M
Run till exit from #0 pck.create_small_float_vector () at pck.adb:30^M
0x00000000100022d4 in p () at p.adb:25^M
25 Vector := Create_Small_Float_Vector;^M
Value returned is $3 = (2.80259693e-45, 2.80259693e-45)^M
(gdb) FAIL: gdb.ada/array_return.exp: value printed by finish of Create_Small_Float_Vector
...
while this is expected:
...
Value returned is $3 = (4.25, 4.25)^M
...
The problem is here in ppc64_aggregate_candidate:
...
if (!get_array_bounds (type, &low_bound, &high_bound))
return -1;
count *= high_bound - low_bound
...
The array type (containing 2 elements) is:
...
type Small_Float_Vector is array (1 .. 2) of Float;
...
so we have:
...
(gdb) p low_bound
$1 = 1
(gdb) p high_bound
$2 = 2
...
but we calculate the number of elements in the array using
"high_bound - low_bound", which is 1.
Consequently, gdb fails to correctly classify the type as a ELFv2 homogeneous
aggregate.
Fix this by calculating the number of elements in the array by using
"high_bound - low_bound + 1" instead.
Furthermore, high_bound can (in general, though perhaps not here) also be
smaller than low_bound, so to be safe take that into account as well:
...
LONGEST nr_array_elements = (low_bound > high_bound
? 0
: (high_bound - low_bound + 1));
count *= nr_array_elements;
...
Tested on powerpc64le-linux.
Approved-By: Ulrich Weigand <uweigand@de.ibm.com>
PR tdep/31015
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31015
This patch adds support for 10 new AArch64 system registers
(gcscre0_el1, gcscr_el1, gcscr_el12, gcscr_el2, gcscr_el3,
gcspr_el0, gcspr_el1 ,gcspr_el12, gcspr_el2 and gcspr_el3),
which are enabled on using Guarded Control Stack (+gcs flag)
feature.
This patch adds support for Guarded control stack data synchronization
instruction (GCSB DSYNC). This instruction is allocated to existing
HINT space and uses the HINT number 19 and to match this an entry is
added to the aarch64_hint_options array.
This patch adds for Guarded Control Stack Extension (GCS) extension. GCS feature is
optional from Armv9.4-A architecture and enabled by passing +gcs option to -march
(eg: -march=armv9.4-a+gcs) or using ".arch_extension gcs" directive in the assembly file.
Also this patch adds support for GCS instructions gcspushx, gcspopcx, gcspopx,
gcsss1, gcsss2, gcspushm, gcspopm, gcsstr and gcssttr.
This patch adds support for Check Feature Status Extension (CHK) which
is mandatory from Armv8.0-A. Also this patch supports "chkfeat" instruction
(hint #40).
* testsuite/ld-x86-64/property-3.r: Update regexp to allow for targets which support x86-64-v3.
* testsuite/ld-x86-64/property-4.r: Likewise.
* testsuite/ld-x86-64/property-5.r: Likewise.
help2man is no longer used to create the gprofng man pages.
gprofng/ChangeLog
2023-10-31 Vladimir Mezentsev <vladimir.mezentsev@oracle.com>
* configure.ac: Remove HELP2MAN.
* Makefile.in: Rebuild.
* configure: Rebuild.
* doc/Makefile.in: Rebuild.
* gp-display-html/Makefile.in: Rebuild.
* src/Makefile.in: Rebuild.
PR 27565
* ldlex.l: Add REVERSE.
* ldgram.y: Allow REVERSE to be used wherever a sorting command can be used.
* ld.h (struct wildcard_spec): Add 'reversed' field.
* ldlang.h (lang_wild_statement_struct): Add 'filenames_reversed' field.
* ldlang.c (compare_sections): Add reversed parameter. (wild_sort): Reverse the comparison if requested. (print_wild_statement): Handle the reversed field.
* ld.texi: Document the new feature.
* NEWS: Mention the new feature.
* testsuite/ld-scripts/sort-file-reversed-1.d: New test driver.
* testsuite/ld-scripts/sort-file-reversed-1.t: New test source.
* testsuite/ld-scripts/sort-file-reversed-2.t: New test source.
* testsuite/ld-scripts/sort-file-reversed-2.d: New test driver.
* testsuite/ld-scripts/sort-sections-reversed-1.d: New test driver.
* testsuite/ld-scripts/sort-sections-reversed-1.t: New test source.
* testsuite/ld-scripts/sort-sections-reversed-2.t: New test source.
* testsuite/ld-scripts/sort-sections-reversed-2.d: New test driver.
* testsuite/ld-scripts/sort-sections-reversed-3.d: New test driver.
* testsuite/ld-scripts/sort-sections-reversed-3.t: New test source.
When running test-case gdb.tui/tui-layout-asm-short-prog.exp on AlmaLinux 9.2
ppc64le, I run into:
...
FAIL: gdb.tui/tui-layout-asm-short-prog.exp: check asm box contents
...
The problem is that we get:
...
7 [ No Assembly Available ]
...
because tui_get_begin_asm_address doesn't succeed.
In more detail, tui_get_begin_asm_address calls:
...
find_line_pc (sal.symtab, sal.line, &addr);
...
with:
...
(gdb) p *sal.symtab
$5 = {next = 0x130393c0, m_compunit = 0x130392f0, m_linetable = 0x0,
filename = "tui-layout-asm-short-prog.S",
filename_for_id = "$gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S",
m_language = language_asm, fullname = 0x0}
(gdb) p sal.line
$6 = 1
...
The problem is the filename_for_id which is the source file prefixed with the
compilation dir rather than the source dir.
This is due to faulty debug info generated by gas, PR28629:
...
<1a> DW_AT_name : tui-layout-asm-short-prog.S
<1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite
<22> DW_AT_producer : GNU AS 2.35.2
...
The DW_AT_name is relative, and it's relative to the DW_AT_comp_dir entry,
making the effective name $gdb/build/gdb/testsuite/tui-layout-asm-short-prog.S.
The bug is fixed starting version 2.38, where we get instead:
...
<1a> DW_AT_name :
$gdb/src/gdb/testsuite/gdb.tui/tui-layout-asm-short-prog.S
<1e> DW_AT_comp_dir : $gdb/build/gdb/testsuite
<22> DW_AT_producer : GNU AS 2.38
...
Work around the faulty debug info by constructing the filename_for_id using
the second directory from the directory table in the .debug_line header:
...
The Directory Table (offset 0x22, lines 2, columns 1):
Entry Name
0 $gdb/build/gdb/testsuite
1 $gdb/src/gdb/testsuite/gdb.tui
...
Note that the used gas contains a backport of commit 3417bfca67 ("GAS:
DWARF-5: Ensure that the 0'th entry in the directory table contains the
current working directory."), because directory 0 is correct. With the
unpatched 2.35.2 release the directory 0 entry is incorrect: it's a copy of
entry 1.
Add a dwarf assembly test-case that reflects the debug info as generated by
unpatched gas 2.35.2.
Tested on x86_64-linux.
Approved-By: Tom Tromey <tom@tromey.com>
This patch implements the DAP setVariable request.
setVariable is a bit odd in that it specifies the variable to modify
by passing in the variable's container and the name of the variable.
This approach can't handle variable shadowing (there are a couple of
open DAP bugs on this topic), so this patch renames duplicates to
avoid the problem.
I stumbled across a few spots that mention that a function
"invalidates frame" and also assignments of NULL to a frame_info_ptr.
This code isn't harmful, but is also unnecessary since the
introduction of frame_info_ptr -- nowadays frame invalidations are
handled automatically.
Regression tested on x86-64 Fedora 38.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
The BPF pseudo-c syntax supports both MOV and LDDW instructions:
mov: r1 = EXPR
lddw: r1 = EXPR ll
Note that the white space between EXPR and `ll' is necessary in order
to avoid ambiguity with the assembler's support for C-like numerical
suffixes. This patch adds a new test to the GAS BPF testsuite to make
sure that instructions like:
r1 = 666ll
are interpreted as `mov %r1,666', not as `lddw %r1,666'.
This matches clang's assembler behavior.
2023-10-30 Jose E. Marchesi <jose.marchesi@oracle.com>
* testsuite/gas/bpf/alu-pseudoc.s: Add test to make sure C-like
suffix `ll' is not interpreted as lddw syntax.
* testsuite/gas/bpf/alu-pseudoc.d: Update expected results.
* testsuite/gas/bpf/alu-be-pseudoc.d: Likewise.
On a big-endian ARM machine, the "return" command resulted in the
wrong value being returned when the function had a fixed-point return
type. This patch fixes the problem by unpacking and repacking the
fixed-point type appropriately.
Approved-By: Luis Machado <luis.machado@arm.com>
On big-endian ARM, "return"ing from a function that returned a range
type did not work. This patch strips the range type to treat the
function as though it were returning the underlying type instead.
Approved-By: Luis Machado <luis.machado@arm.com>
On a big-endian ARM system, "finish" printed the wrong value when
finishing from a function that returned a vector type. Similarly,
calls to a function also resulted in the wrong value being passed. I
think both the read- and write-functions here should ignore the
endian-ness.
I tested this using the AdaCore internal test suite; the test case
that caught this is identical to gdb.base/gnu_vector.exp.
Approved-By: Luis Machado <luis.machado@arm.com>
On ARM (I tested big-endian but it may not matter), "finish" can
sometimes print the wrong result when the return type is a range type.
Range types should really be treated as their underlying type
(normally integer, but sometimes fixed-point). This patch implements
this.
Approved-By: Luis Machado <luis.machado@arm.com>
On big-endian ARM, an inferior call with a small integer will pass the
wrong value. This patch fixes the problem. Because the code here
works using scalar values, and not just bytes, left-shifting is
unnecessary.
Approved-By: Luis Machado <luis.machado@arm.com>
Given the shared use of the aarch64-sys-regs.def file across Binutils
and GCC, add instructions for keeping the file synchronized across the
two codebases.
Namely, it should be made clear that all changes are first to be made
in Binutils and the updated file copied across to GCC.
opcodes/ChangeLog
* opcodes/aarch64-sys-regs.def: Update file-description header
comment.
In the interest of shrinking dwarf2/read.c a little more, this patch
moves the code that deciphers .debug_aranges into a new file.
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
While working on background DWARF reading, I found a race case that I
tracked down to the handling of the .debug_aranges section. Currently
the section data is only read in after the CUs have all been created.
However, there's no real reason to do this -- it seems fine to read it
a little earlier, when all the other necessary sections are read in.
This patch makes this change, and updates the
read_addrmap_from_aranges API to assert that the section is read in.
This patch slightly changes the read_addrmap_from_aranges API as well,
to reject an empty section. This seems better to me than what the
current code does, which is try to read an empty section but then do
no work.
Regression tested on x86-64 Fedora 38.
Reviewed-By: Guinevere Larsen <blarsen@redhat.com>
This patch proposes to require a C++17 compiler to build gdb /
gdbsupport / gdbserver. Before this patch, GDB required a C++11
compiler.
The general policy regarding bumping C++ language requirement in GDB (as
stated in [1]) is:
Our general policy is to wait until the oldest compiler that
supports C++NN is at least 3 years old.
Rationale: We want to ensure reasonably widespread compiler
availability, to lower barrier of entry to GDB contributions, and to
make it easy for users to easily build new GDB on currently
supported stable distributions themselves. 3 years should be
sufficient for latest stable releases of distributions to include a
compiler for the standard, and/or for new compilers to appear as
easily installable optional packages. Requiring everyone to build a
compiler first before building GDB, which would happen if we
required a too-new compiler, would cause too much inconvenience.
See the policy proposal and discussion
[here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html).
The first GCC release which with full C++17 support is GCC-9[2],
released in 2019[3], which is over 4 years ago. Clang has had C++17
support since Clang-5[4] released in 2018[5].
A discussions with many distros showed that a C++17-able compiler is
always available, meaning that this no hard requirement preventing us to
require it going forward.
[1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F
[2] https://gcc.gnu.org/projects/cxx-status.html#cxx17
[3] https://gcc.gnu.org/gcc-9/
[4] https://clang.llvm.org/cxx_status.html
[5] https://releases.llvm.org/
Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Approved-By: Pedro Alves <pedro@palves.net>
