Commit bedd6a7a44 ("gdb/dwarf: track compilation and type unit count")
causes this internal error:
$ ./gdb -nx -q --data-directory=data-directory testsuite/outputs/gdb.dwarf2/debug-names-duplicate-cu/debug-names-duplicate-cu -ex "save gdb-index -dwarf-5 /tmp" -batch
warning: Section .debug_names has incorrect number of CUs in CU table, ignoring .debug_names.
/home/smarchi/src/binutils-gdb/gdb/dwarf2/index-write.c:1454: internal-error: write_debug_names: Assertion `comp_unit_counter == per_bfd->num_comp_units' failed.
This is visible when running this test:
$ make check TESTS="gdb.dwarf2/debug-names-duplicate-cu.exp" RUNTESTFLAGS="--target_board=cc-with-debug-names"
...
Running /home/smarchi/src/binutils-gdb/gdb/testsuite/gdb.dwarf2/debug-names-duplicate-cu.exp ...
gdb compile failed, warning: Section .debug_names has incorrect number of CUs in CU table, ignoring .debug_names.
/home/smarchi/src/binutils-gdb/gdb/dwarf2/index-write.c:1454: internal-error: write_debug_names: Assertion `comp_unit_counter == per_bfd->num_comp_units' failed.
...
=== gdb Summary ===
# of untested testcases 1
However, it's easy to miss because it only causes an "UNTESTED" to be
recorded, not a FAIL or UNRESOLVED. This is because the problem happens
while trying to create the .debug_names index, as part of the test case
compilation.
The problem is: when we bail out from using .debug_names because we
detect it is inconsistent with the units in .debug_info, we clear
per_bfd->all_units, to destroy all units previously created, before
proceeding to read the units with an index. However, we don't clear
per_bfd->num_{comp,type}_units. As a result, per_bfd->all_units
contains one unit, while per_bfd->num_comp_units is 2. Whenever we
clear per_bfd->all_units, we should also clear
per_bfd->num_{comp,type}_units.
While at it, move this logic inside a scoped object.
I added an assertion in finalize_all_units to verify that the size of
per_bfd->all_units equals per_bfd->num_comp_units +
per_bfd->num_type_units. This makes the problem (if omitting the fix)
visible when running gdb.dwarf2/debug-names-duplicate-cu.exp with the
unix (default) target board:
ERROR: Couldn't load debug-names-duplicate-cu into GDB (GDB internal error).
FAIL: gdb.dwarf2/debug-names-duplicate-cu.exp: find index type (GDB internal error)
FAIL: gdb.dwarf2/debug-names-duplicate-cu.exp: find index type, check type is valid
=== gdb Summary ===
# of expected passes 1
# of unexpected failures 2
# of unresolved testcases 1
I considered changing the code to build a local vector of units first,
then move it in per_bfd->all_units on success, that would avoid having
to clean it up on error. I did not do it because it's a much larger
change, but we could consider it.
Change-Id: I49bcc0cb4b34aba3d882b27c8a93c168e8875c08
Approved-By: Tom Tromey <tom@tromey.com>
The convenience function get_frame_pc_if_available would take a pointer
to a variable that should be set if available, and would return a
boolean indicating whether that action was successful or not.
Now that GDB supports C++17 features, this indirection of a pointer and
returning boolean is unnecessary, since the function can return an
optional, and code that calls it can check if the optional contains a
value.
This commit makes that modernization. It should have no visible
effects.
Approved-By: Tom Tromey <tom@tromey.com>
In lib/tuiterm.exp we have:
...
namespace eval Term {
variable ...
...
}
...
with everything within the namespace (which is basically the entire file)
indented, which wastes screen space and makes editing more involved.
We could maybe fix this by moving the "namespace eval Term" to tuiterm_env,
but I don't think it's a good idea to move it out of the file.
Another idea is to have the file include itself, wrapped in the namespace:
...
if { ![info exists Term::_in_namespace] } {
namespace eval Term {
# Read the rest of this file, wrapped in this namespace.
variable _in_namespace
set _in_namespace 1
source $::srcdir/lib/tuiterm.exp
unset _in_namespace
return
}
}
variable ...
...
but this was considered unnecessarily complex.
Fix this in the style of lib/ton.tcl and lib/completion-support.exp:
- only declare the variables in the namespace, and
- define the procs using a Term:: prefix.
As a side-effect, this works around an emacs bug that makes editing
lib/tuiterm.exp in its current form problematic because the auto-indentation
keeps removing required indentation of all but the first proc [1].
Tested on x86_64-linux.
[1] https://lists.gnu.org/archive/html/bug-gnu-emacs/2020-11/msg01674.html
GDB has support for many binary file formats, some which might be very
unlikely to be found in some situations (such as the XCOFF format in
an x86 system). This commit introduces the option for a user to choose
which formats GDB will support at build configuration time.
This is especially useful to avoid possible security concerns with
readers that aren't expected to be used at all, as they are one of
the simplest vectors for an attacker to try and hit GDB with. This
change can also reduce the size of the final binary, if that is a
concern.
This commit adds a switch to the configure script allowing a user to
only enable selected file formats, called --enable-binary-file-formats.
The default behavior when the switch is omitted is to compile all file
formats, keeping the original behavior of the script. At the time of
this commit, the valid options for this option are: dbx, coff (which
includes coff-pe), xcoff, mips, elf, macho and all. All is treated
especially, activating all supported readers.
A few targets may require specific binary file format support, as they
directly call functions defined by the file reader. Specifically,
windows targets require coff support, and rs6000 aix and lynx178 targets
require xcoff support. Considering that those formats are the main - or
only - one available in those targets, I believe it makes sense to
re-enable those readers. If that happens, the script will emit the
following warning:
FOO is required to support one or more requested targets. Adding it
Users aren't able to force the disabling of those formats, since GDB
will not compile without those readers. Ideally we'd like to be able
to disable even those formats, in case a user wants to build GDB only
to examine remote files for example, but the current infrastructure
for the file format readers doesn't allow us to do it.
Mach-O and elf support are also dependent on BFD support being compiled
in. In case one of those was requested and BFD does not support them,
the following error is emitted:
FOO was requested, but BFD does not support it.
Finally, this configure switch is also printed by the "show
configuration" command in GDB.
Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Tom Tromey <tom@tromey.com>
Fix PR ld/33199 SEGV in _bfd_x86_elf_create_sframe_plt
Currently, the selection for sframe_plt was not being done (and simply
set to NULL) for the case when !normal_target, causing SEGV on Solaris.
Initialize sframe_plt to init_table->sframe_lazy_plt when lazy_plt is
true, and NULL otherwise. This is in line with htab->non_lazy_plt being
set to NULL for !normal_target.
bfd/
PR ld/33199
* elfxx-x86.c (_bfd_x86_elf_link_setup_gnu_properties):
Setup sframe_plt for !normal_target.
In a later commit I'd like to add support to GDB for including the
NT_386_TLS note in the core files that GDB creates (using 'gcore'
command).
To achieve this we need some standard boilerplate code added to bfd.
The only part of this patch which I think needs consideration is the
name I selected for the pseudo section to hold the note contents when
a core file is loaded. I chose '.reg-i386-tls'. The '.reg' prefix is
the standard used by most other pseudo sections, and the '-i386-tls'
suffix seemed to match the note name, though I added the 'i' to
'i386', instead of just using '.reg-386-tls'. I thought 'i386' seemed
clearer.
There's no test included here, but when I merge the NT_386_TLS
creation to GDB it will depend on this and act as a test. I plan to
post that work to the GDB list once this patch is merged.
Use stat, instead of strcmp, to check if the same linker script file
appears multiple times for
$ ld -L... -T ././/script.t -T script.t ...
Although ././/script.t and script.t access the same file, but their
filenames are different. strcmp won't work here.
Copy gnulib/import/same-inode.h to include since the gnulib directory
isn't included in the binutils tarball.
include/
PR ld/24576
* same-inode.h: New file. Copied from gnulib/import/same-inode.h.
ld/
PR ld/24576
* ldfile.c: Include "same-inode.h".
(ldfile_find_command_file): Change the second argument from bool
to enum script_open_style. Check if the same linker script file
appears multiple times by using stat, instead using strcmp.
(ldfile_open_command_file_1): Don't check if the same linker
script file appears multiple times here.
* testsuite/ld-scripts/pr24576-1.d: Adjusted.
* testsuite/ld-scripts/pr24576-2.d: New.
* testsuite/ld-scripts/script.exp: Run pr24576-2.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
On x86_64-freebsd, with test-case gdb.tui/main.exp, I ran into a failure to
match the output of the file command, for which I submitted a patch [1].
However, after switching to TERM=ansiw for bsd, I could no longer reproduce
the problem.
Investigation showed that the difference was caused by CLI styling.
A command:
...
(gdb) file <filename>
...
gives an output:
...
Reading symbols from <filename>...
(gdb)
...
On x86_64-linux, with CLI styling I get:
...
Reading symbols from ^[[32m/data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main^[[39m^[[0;10m...
...
After disabling CLI styling using "set style enabled off", I simply get:
...
Reading symbols from /data/vries/gdb/leap-15-6/build/gdb/testsuite/outputs/gdb.tui/main/main...
...
and run into the same failure as on x86_64-freebsd.
The extra csi sequence "^[[32m" causes an additional matching attempt in
Term::wait_for, and the way we're currently matching relies on this:
...
send_gdb "file [standard_output_file $testfile]\n"
gdb_assert { [Term::wait_for "Reading symbols from"] } "file command"
...
Make the TUI testsuite more stable and matching more simple by disabling CLI
styling by default, and:
- fix the resulting fallout in test-cases gdb.tui/main.exp and
gdb.tui/new-layout.exp, and
- re-enable CLI styling in the one test-case that needs it:
gdb.tui/tui-disasm-styling.exp.
Tested on x86_64-linux.
[1] https://sourceware.org/pipermail/gdb-patches/2025-June/218942.html
Recognise ECOFF archives and reject them so that the ecoff archive
support has a chance to handle the archive. Also use memcmp rather
than startswith (strncmp) as we know the string length.
* archive.c (bfd_slurp_armap): Recognize ECOFF armap. Use memcmp
to match names, and tidy buffer sizes.
This tidies objcopy/strip handling of IR objects, in the process of
removing the unnecessary is_strip_input flag.
The first thing I noticed when looking at is_strip_input code was that
the abfd->my_archive test in bfd_check_format_matches meant that
plugins were disabled when reading archive elements. We can instead
disable plugins by setting bfd_no_plugin, so there doesn't seem to be
a need for is_strip_input in objcopy.c:copy_archive. This isn't
exactly the same, because bfd_no_plugin prevents the plugin target
recognising archive elements in the bfd_check_format_matches loop over
all targets as well as just the first !target_defaulted test. But
that turns out to be fine. IR code is handled in copy_archive as for
other unknown format files. In fact, the only need for the plugin
target when copying archives is when reading symbols for the archive
map. I've made that plain by moving the plugin target override and
commenting on why it is really needed.
So on to plain object files. Here, IR code is also copied unchanged,
so there doesn't seem a need for the plugin target there either. It
isn't quite so simple though, because the objcopy/strip code handling
object files wants to verify the format of the object file. Allowing
objcopy/strip to copy unknown format files would be a change in
behaviour (and results in mmix testsuite fails, ld-mmix/b-badfil1 and
others). However, always excluding the plugin target results in a
fail of tests added in commit c2729c37f1. So I've enabled a plugin
format check only for files that are otherwise unrecognised, and
commented why this is done. I question the need to objcopy LLVM
bytecode files.
bfd/
* bfd.c (struct bfd<is_strip_input>): Delete.
* format.c (bfd_check_format_matches): Delete is_strip_input
special case code.
* bfd-in2.h: Regenerate.
binutils/
* objcopy.c (copy_archive): Don't set is_strip_input. Always
set bfd_plugin_no when reading elements. Enable plugins when
opening copied elements.
(check_format_object): Delete.
(copy_file): Don't enable plugin target here. Don't set
is_strip_input. Set bfd_plugin_no. Move bfd_core handling
code earlier to remove goto. Enable plugin for llvm bytecode.
Copy slim IR files as unknown objects.
If we have an existing archive, the test may fail due to it being the
wrong format. Also, downloading bintest.thin.a from a remote host
(before creating it!) is wrong.
* testsuite/binutils-all/readelf.exp (readelf_thin_archive_test):
Don't remote_download bintest.thin.a. Delete lib before
creating.
On x86_64-freebsd, I run into:
...
Box Dump (80 x 24) @ (0, 0):
0 (gdb) maint info screen
1 Number of characters gdb thinks are in a line is 90.
2 Number of characters readline reports are in a line is 89.
3 Number of characters curses thinks are in a line is 90.
4 Number of characters environment thinks are in a line is 90 (COLUMNS).
5 Number of lines gdb thinks are in a page is 40.
6 Number of lines readline reports are in a page is 40.
7 Number of lines curses thinks are in a page is 40.
8 Number of lines environment thinks are in a page is 40 (LINES).
9 Readline wrapping mode: readline (terminal is not auto wrap capable, last column
10 .
11 (gdb) tui disable
12 (gdb) tui disable
13 (gdb) maint info screen
14
15
16
17
18
19
20
21
22
23
FAIL: gdb.tui/resize-2.exp: again: curses width 80
...
The problem is that the prompt matching in Term::wait for is not strict enough.
It will accept a line:
...
(gdb) foo
...
as long as the cursor is pointing just after the prompt, like so:
...
(gdb) foo
^
...
Fix this by also checking that the line is empty.
Tested on x86_64-linux.
With a gdb build with gcc 15.1.1 and "-O2 -flto=auto -g", I run into:
...
UNTESTED: gdb.gdb/selftest.exp: \
Cannot set breakpoint at captured_main, skipping testcase.
UNTESTED: gdb.gdb/python-helper.exp: \
Cannot set breakpoint at captured_main, skipping testcase.
...
I don't know why we're trying to stop in captured_main.
Stopping in main also works, and main is more likely to be present in an lto
build.
Fix this by using main instead.
This requires us to update the expected file name from main.c to gdb.c in
selftest_setup.
After doing so, we get:
...
XFAIL: gdb.gdb/selftest.exp: \
run until breakpoint at main (line numbers scrambled?)
XFAIL: gdb.gdb/python-helper.exp: \
run until breakpoint at main (line numbers scrambled?)
...
because main is reported to be in run-on-main-thread.c instead of gdb.c:
.
Breakpoint 1, main (...) at gdb/run-on-main-thread.c:120^M
...
This is due to picking the last line entry for pc == 0x455e40 that has
is_stmt == true:
...
File name Line number Starting address View Stmt
gdb/gdb.c:
gdb.c 25 0x455e40 x
gdb.c 30 0x455e40 1 x
gdb/run-on-main-thread.c:
run-on-main-thread.c 116 0x455e40 2 x
run-on-main-thread.c 120 0x455e40 3 x
gdb/gdb.c:
gdb.c 25 0x455e40 4
/usr/include/c++/15/bits/std_thread.h:
std_thread.h 366 0x455e4b
...
While we're at it, update the corresponding gdb_test_multiple in
selftest_setup using multi_line and -wrap.
Tested on x86_64-linux.
PR cli/21690 reports the following: say we start gdb:
...
$ gdb -q
(gdb)
...
and press ^R for reverse-i-search:
...
(reverse-i-search)`':
...
Pressing the p key has the effect of showing both the pressed key and a
matching entry, which happens to be up:
...
(reverse-i-search)`p': up
...
Now we press ^C to cancel the search:
...
(reverse-i-search)`p': u❌️ Quit
(gdb)
...
and type "down".
We expected to get:
...
(gdb) down
...
but instead we get:
...
(failed reverse-i-search)`pdown':
...
So we're stuck in reverse-i-search, until we use the workaround of ^G.
The same problem happened with python [1], was reported upstream [2], and
fixed in cpython commit d6990d221b0 ("Issue #24266: Cancel history search mode
with Ctrl+C in Readline 7") using rl_callback_sigcleanup.
Fix this likewise in quit using rl_callback_sigcleanup, a new callback
function in readline 7.0:
...
i. rl_callback_sigcleanup: a new application function that can clean up and
unset any state set by readline's callback mode. Intended to be used
after a signal.
...
giving us instead:
...
$ gdb
(gdb) u❌️ Quit
(gdb) down
...
Remove the corresponding kfail in gdb.tui/pr30056.exp.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21690
[1] https://bugs.python.org/issue24266
[2] https://lists.gnu.org/archive/html/bug-readline/2015-05/msg00014.html
The original patch,
e6f372ba66
Since recently c.slli64, c.srai64, and c.srli64 have been removed from the
riscv-isa-manual, c.slli, c.srli, and c.srai with 0 immediate are now listed
as hints,
https://github.com/riscv/riscv-isa-manual/pull/1942 and https://github.com/riscv/riscv-isa-manual/pull/2093
So allow c.slli, c.srli, and c.srai with 0 immediate as a hint. Also allow to
assemble slli, srli and srai with 0 immediate to hint c.slli, c.srli and c.srai
when rvc is enabled. The c.slli64, c.srai64, and c.srli64 should be kept as
aliases, so dis-assembler should disassemble to c.slli, c.srli, and c.srai with
0 immediate.
Passed rv32/64-elf/linux binutils testcases.
gas/
PR 33216
* testsuite/gas/riscv/c-zero-imm.d: Updated since allow c.slli64,
c.srai64, and c.srli64 with 0 immediate as a hint.
* testsuite/gas/riscv/c-zero-imm.s: Likewise.
* testsuite/gas/riscv/zca.d: Likewise.
opcodes/
PR 33216
* riscv-opc.c (riscv_opcodes): Updated since allow c.slli64, c.srai64,
and c.srli64 with 0 immediate as a hint.
PR symtab/33247 points out that this check in
create_addrmap_from_gdb_index:
if (lo > hi)
{
complaint (_(".gdb_index address table has invalid range (%s - %s)"),
hex_string (lo), hex_string (hi));
... should probably use ">=" instead. Reading a bit further the
reason seems obvious:
mutable_map.set_empty (lo, hi - 1, index->units[cu_index]);
Here if lo==hi, then this will insert a "reversed" range into the
addrmap.
Apparently some LLVM tool can erroneously create a .gdb_index like
this.
No test because it seems like more trouble to write than it's worth.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33247
Approved-By: Simon Marchi <simon.marchi@efficios.com>
captured_main takes a 'void *', but then immediately casts it to the
correct type. There's no reason for this any more, the caller passes
in the correct type. This patch cleans this up. Tested by
rebuilding.
Remove AM_PROG_CC_STDC, the correct macro AC_PROG_CC is already being
used.
Update AC_OUTPUT (file list, [cmd list]) by adding the file list to
the previous AC_CONFIG_FILES and using AC_CONFIG_COMMANDS to output
the command list.
Approved-By: Tom Tromey <tom@tromey.com>
Function tui_disassemble (with addr_size parameter) has two modes of
operation:
- addr_size != nullptr, and
- addr_size == nullptr.
I noticed that for the addr_size == nullptr case, more than necessary is done.
Fix this by using continue and null_stream.
While we're at it, eliminate the unnecessary variables new_size and orig_pc.
Tested on x86_64-linux.
Approved-By: Andrew Burgess <aburgess@redhat.com>
In test-case gdb.base/watchpoint-unaligned.exp, in function write_size8twice,
two adjacent 8-byte vars are written. For aarch64, we use a single stp
instruction for that.
If we do the same in function read_size8twice for two adjacent 8-byte var reads
using aarch64 insn ldp, on an aarch64-linux M1 system we get a hang:
...
(gdb) continue^M
Continuing.^M
FAIL: $exp: fun=read_size8twice: offset=0: index=1: continue (timeout)
FAIL: $exp: fun=read_size8twice: offset=0: index=1: $got_hit
...
The same problem was observed for stp in PR tdep/29423, fixed by commit
9a03f21853 ("[gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64").
See that commit for an explanation of the hang.
That commit introduced max_access_size in aarch64_stopped_data_address:
...
The access size also can be larger than that of the watchpoint
itself. For instance, the access size of an stp instruction is 16.
So, if we use stp to store to address p, and set a watchpoint on
address p + 8, the reported ADDR_TRAP can be p + 8 (observed on
RK3399 SOC). But it also can be p (observed on M1 SOC). Checking
for this situation introduces the possibility of false positives,
so we only do this for hw_write watchpoints. */
const CORE_ADDR max_access_size = type == hw_write ? 16 : 8;
...
If we say that hangs are worse than false positives, then we should also fix
this case.
Fix this by setting max_access_size to 16 for all watchpoint types.
Tested on aarch64-linux, both on an M1 SOC and an RK3399 SOC.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Extend the part of gdb.base/watchpoint-unaligned.exp handling
write_size8twice to also check read hardware watchpoints.
Tested on x86_64-linux.
Approved-By: Luis Machado <luis.machado.foss@gmail.com>
Improve the part of gdb.base/watchpoint-unaligned.exp handling
write_size8twice:
- move the code into a proc
- use -wrap
- use $decimal more often
- don't use gdb_test_multiple $test $test
- add comments
- start test when entering write_size8twice function, instead of main
- finish test when leaving write_size8twice function, instead of main
- add insn in between:
- insn triggering watchpoint, and
- insn triggering breakpoint
to ensure that the watchpoint triggers before the breakpoint, and
add a comment explaining this.
Tested on x86_64-linux.
This patch changes type::fields to return an array_view of the fields,
then fixes up the fallout.
More cleanups would be possible here (in particular in the field
initialization code) but I haven't done so.
The main motivation for this patch was to make it simpler to iterate
over the fields of a type.
Regression tested on x86-64 Fedora 41.
Approved-By: Simon Marchi <simon.marchi@efficios.com>
A buildbot pointed out that my changes to gdb.dap/scopes.exp caused a
test failure. The new code iterates over all the registers, fetching
their children (when possible). The failure comes because this code
failed to consider that a register might have "indexed" children,
which I believe can occur when a register is vector-like.
This patch fixes the problem by arranging to fetch indexed children
when indicated.
Add Linux/x86-64 support to export-class.exp by passing --32 to assembler
and passing -melf_i386 to linker.
* testsuite/ld-i386/export-class.exp: Run for Linux/x86-64.
Pass --32 to assembler. Pass -melf_i386 to linker.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
PR dap/33228 points out a failure that occurs when the DAP client
requests more children of a variable than actually exist. Currently,
gdb throws a somewhat confusing exception. This patch changes this
code to throw a DAPException instead, resulting in a more ordinary and
readable failure.
The spec seems to be silent on what to do in this case. I chose an
exception on the theory that it's easier to be strict now and lift the
restriction later (if needed) than vice versa.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228
While investigating a different bug, I noticed that the DAP code would
report a "void *"-typed register as having children -- however,
requesting the children of this register would fail.
The issue here is that a plain "void *" can't be dereferenced. This
patch changes the default visualizer to treat a "void *" as a scalar.
This adds a new test; but also arranges to examine all the returned
registers -- this was the first thing I attempted and it seemed
reasonable to have a test that double-checks that all the registers
really can be dereferenced as appropriate.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33228
If all external symbol accesses are indirect, we can treat protected
symbols as local since there will be no copy relocation for data and
external function pointer access will go through GOT, instead of PLT.
No PLT slot should be used for external function pointer in executable.
bfd/
PR ld/33260
* elfxx-x86.h (COPY_INPUT_RELOC_P): Treat protected symbols with
indirect external access as local.
ld/
PR ld/33260
* testsuite/ld-i386/i386.exp: Run PR ld/33260 test.
* testsuite/ld-x86-64/x86-64.exp: Likewise.
* testsuite/ld-i386/pr33260.d: New file.
* testsuite/ld-i386/pr33260.s: Likewise.
* testsuite/ld-x86-64/pr33260-x32.d: Likewise.
* testsuite/ld-x86-64/pr33260.d: Likewise.
* testsuite/ld-x86-64/pr33260.s: Likewise.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
Otherwise, the same test appears twice, once with PASS, once with UNSUPPORTED
on non-ia64. Just add '(ia64)' to the name so binutils.log is clearer.
* testsuite/binutils-all/testranges-ia64.d (#name): Add suffix.
Pass $plug_opt to nm when setting dump_prog to nm to load plugin.
PR binutils/21479
* testsuite/ld-plugin/lto-binutils.exp (run_lto_binutils_test):
Pass $plug_opt to nm.
Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
should_validate_memtags uses value_as_address to evalute
whether an address for a value is tagged. The comments for
that function simply say, "Extract a value as a C pointer."
While that sounds innoncuous, that function calls coerce_array,
which will dereference any references. This is not what is
desired here.
This can be demonstrated on an MTE-enabled host, such as aarch64-
based Ampere (example taken from tests introduced in this patch):
(gdb) p b.get_foo ()
Could not validate memory tag: Value can't be converted to integer.
$2 = (const foo &) @0xffffffffed88: {m_a = 42}
While the command completes, gdb didn't actually attempt to
evaluate any memory tags.
Fix this by using unpack_pointer instead.
Tested on x86_64 Fedora 40 and aarch64 RHEL 9.6.
With test-case gdb.tui/basic.exp and TERM=ansis, I run into (with some logging
added):
...
status line: '<reverse:1><intensity:dim>exec No process (asm) In:
L?? PC: ?? <reverse:0><intensity:normal>'
FAIL: gdb.tui/basic.exp: status window: reverse
...
The status window uses ncurses attribute standout, which can differ between
different terminal settings.
Fix this by making the matching less strict.
Tested on x86_64-linux.
When running test-case gdb.tui/main-2.exp with TERM=ansis, I get:
...
screen line 6: 'B+><fg:black><intensity:bold> 21 <reverse:1><fg:default><intensity:normal> return 0;<reverse:0> '
FAIL: gdb.tui/main-2.exp: highlighted line in middle of source window
...
The test tries to check the highlighting of the source line, but also gets the
part with the line number, which makes it more complicated to parse.
Fix this by getting just the part with the source line:
...
screen line 6: '<reverse:1> return 0;<reverse:0> \
'
...
Tested on x86_64-linux.
While investigating using TERM=ansiw for freebsd, I also came across
TERM=ansis which unlike ansiw is present on both linux and freebsd.
Add initial support for TERM=ansi in tuiterm:
- handle ansis in Term::_have_bw
- add Term::_csi_x to support (well, ignore) DECREQTPARM
(Request Terminal Parameters)
This is sufficient to make the TUI testsuite pass on x86_64-freebsd.
The test-case gdb.tui/tui-layout-asm-short-prog.exp uses an assembly file
gdb.tui/tui-layout-asm-short-prog.S that it compiles using -nostdlib and
-nostartfiles.
However, on x86_64-linux the resulting executable still has dependencies on
libm and libc:
...
$ ldd outputs/gdb.tui/tui-layout-asm-short-prog/tui-layout-asm-short-prog
linux-vdso.so.1 (0x00007ffddf3ec000)
libm.so.6 => /lib64/libm.so.6 (0x00007f8b13406000)
libc.so.6 => /lib64/libc.so.6 (0x00007f8b13000000)
/lib64/ld-linux-x86-64.so.2 (0x00007f8b1350f000)
...
due -lm being added by default_target_compile.
On x86_64-freebsd, using -nostdlib and -nostartfiles in combination with -lm
causes the compilation to fail.
Fix this by using -static as well.
Tested on x86_64-linux and x86_64-freebsd.
On x86_64-freebsd, with test-case gdb.base/exprs.exp I get:
...
(gdb) print 23
yydebug: state 0, reading 257 (INT)
yydebug: state 0, shifting to state 1
yydebug: state 1, reducing by rule 94 (exp : INT)
yydebug: after reduction, shifting from state 0 to state 59
yydebug: state 59, reading 0 (end-of-file)
yydebug: state 59, reducing by rule 7 (exp1 : exp)
yydebug: after reduction, shifting from state 0 to state 60
yydebug: state 60, reducing by rule 1 (start : exp1)
yydebug: after reduction, shifting from state 0 to state 58
$220 = 23
(gdb) FAIL: gdb.base/exprs.exp: print with debugging
...
The test fails because it's not finding the string "Starting parse".
In this case, the .y files are processed used byacc. I suppose the testcase
matches the case that bison is used.
Fix this by grepping for something more generic: shift or Shift.
Tested on x86_64-linux and x86_64-freebsd.
There's no reason to have the compiler materialize objects onto the
stack. And there's also no reason to allow comb[] and name_table[] to be
modifiable.
There's no reason for riscv_all_supported_ext[] to appear in libbfd.so's
dynamic symbol table. There's also no reason for various pieces of data
to live in .data, when .data.rel.ro or even .rodata can do.
... and const. There's no reason to have the compiler copy anonymous
objects onto the stack. And there's also no reason to allow the arrays
to be modifiable.
The custom parsing done there and in one of its callers allowed various
bogus constructs to be accepted. Insist on a non-zero leading digit when
parsing numbers, don't lose upper bits, and insist on proper separation
of operands.
