Add template functions assign_return_if_changed and assign_set_if_changed in
gdb/utils.h:
...
template<typename T> void assign_set_if_changed (T &lval, const T &val, bool &changed)
{ ... }
template<typename T> bool assign_return_if_changed (T &lval, const T &val)
{ ... }
...
This allows us to rewrite code like this:
...
if (tui_border_attrs != entry->value)
{
tui_border_attrs = entry->value;
need_redraw = true;
}
...
into this:
...
need_redraw |= assign_return_if_changed<int> (tui_border_attrs, entry->value);
...
or:
...
assign_set_if_changed<int> (tui_border_attrs, entry->value, need_redraw);
...
The names are a composition of the functionality. The functions:
- assign VAL to LVAL, and either
- return true if the assignment changed LVAL, or
- set CHANGED to true if the assignment changed LVAL.
Tested on x86_64-linux.
gas/
PR binutils/30551
* config/tc-riscv.c (md_atof): Use target_big_endian instead of
TARGET_BYTES_BIG_ENDIAN.
* testsuite/gas/riscv/float-be.d: New file.
* testsuite/gas/riscv/float-le.d: New file.
* testsuite/gas/riscv/float.s: New file.
In commit e2adba909e ("[gdb/testsuite] Clean up before compilation in
gdb.ada/call-no-debug.exp") I added some code in the test-case to remove some
files at the start of the test-case:
...
remote_file host delete [standard_output_file prog.o]
remote_file host delete [standard_output_file prog.ali]
...
Replace this with cleaning up the entire directory instead, for all
test-cases.
Tested on x86_64-linux.
Suggested-By: Tom Tromey <tom@tromey.com>
Reviewed-By: Tom Tromey <tom@tromey.com>
on openSUSE Leap 42.3, with python 3.4, I run into a
"SyntaxError: invalid syntax" due to usage of an f-string in test-case
gdb.python/py-unwind.py.
Fix this by using string concatenation using '+' instead.
Tested on x86_64-linux.
When running test-case gdb.arch/i386-disp-step.exp with target board
unix/-m32/-fPIE/-pie we run into:
...
gdb compile failed, ld: i386-disp-step0.o: warning: relocation in read-only section `.text'
ld: warning: creating DT_TEXTREL in a PIE
...
Fix this by adding nopie in the compilation flags.
Likewise in a few other test-cases.
Tested on x86_64-linux.
In test-case gdb.dwarf2/implptr.exp I noticed:
...
} elseif {![is_x86_like_target]} {
# This test can only be run on x86 targets.
unsupported "needs x86-like target"
return 0
}
...
Use instead "require is_x86_like_target".
Tested on x86_64-linux.
Running test-case gdb.ada/call-no-debug.exp with target board unix/-m64 works
fine, but if we run it again with target board unix-m32, we run into:
...
gnatlink prog.ali -m32 -g -o prog^M
ld: i386:x86-64 architecture of input file `b~prog.o' is incompatible with \
i386 output^M
...
This is due to compiling with no-force.
The test-case:
- first compiles pck.adb into pck.o (without debug info), and
- then compiles prog.adb and pck.o into prog (with debug info).
Using no-force in the second compilation make sure that pck.adb is not
compiled again, with debug info.
But it also means it will pick up intermediate files related to prog.adb from
a previous compilation.
Fix this by removing prog.o and prog.ali before compilation.
Tested on x86_64-linux.
In commit 0f2cd53cf4 ("[gdb/testsuite] Handle missing .note.GNU-stack") I
updated a gdb.arch/arm*.S test-case to use %progbits rather than @progbits,
but failed to do so for gdb.arch/thumb*.S. Fix this oversight.
Tested on arm-linux-gnueabihf.
Because _bfd_read_unsigned_leb128 is hidden visibility, so it can't
be referenced out of shared object.
The new function loongarch_get_uleb128_length just used to call
_bfd_read_unsigned_leb128.
bfd/ChangeLog:
* elfxx-loongarch.c (loongarch_get_uleb128_length): New function.
* elfxx-loongarch.h (loongarch_get_uleb128_length): New function.
gas/ChangeLog:
* config/tc-loongarch.c (md_apply_fix): Use
loongarch_get_uleb128_length.
It's been some time since the switch from Freenode to Libera.Chat,
however, there's still a reference to Freenode in the 'gdb --help'
output. Lets update that.
The logic can actually be expressed with less code that way, utilizing
that there are common patterns of when which form of masking is
permitted. This then also eliminates the large set of open-codings of
BOTH_MASKING in the opcode table.
Commit 3c0afdb789 regressed this test for hppa64, because the test
had been enabled for hppa64 in the time between the mips changes and
their reversion. This patch isn't just a simple reapply, I recreated
the testsuite change by hand for hppa64: Two lines in eh5.d might need
further changes for mips.
Reformat `-modd-spreg'/`-mno-odd-spreg' test invocations in mips.exp to
fit in 79 columns
gas/
* testsuite/gas/mips/mips.exp: Reformat
`-modd-spreg'/`-mno-odd-spreg' test invocations.
Allegrex supports some MIPS32 and MIPS32r2 instructions (albeit with
some encoding differences) such as bit manipulation (ins/ext) and MLA
(madd/msub). It also features some new instructions like wsbw and
min/max or device-specific ones such as mfic.
Signed-off-by: David Guillen Fandos <david@davidgf.net>
The Allegrex CPU supports bit rotation instructions as described in the
MIPS32 release 2 CPU (even though it is a MIPS-2 based CPU).
Signed-off-by: David Guillen Fandos <david@davidgf.net>
The Allegrex CPU was created by Sony Interactive Entertainment to power
their portable console, the PlayStation Portable.
The pspdev organization maintains all sorts of tools to create software
for said device including documentation.
Signed-off-by: David Guillen Fandos <david@davidgf.net>
Rewrite the paragraph to match the style of Tag_GNU_MIPS_ABI_FP text
immediately above, correcting grammar and formatting at the same time.
gas/
* doc/as.texi (MIPS Attributes): Correct Tag_GNU_MIPS_ABI_MSA
attribute description.
After commit 7ade0f1582 I was seeing bfin-elf +XPASS: weak symbols,
and on looking into the bfin targets a little, discovered we have two
bfin-linux targets. One, bfin-uclinux, is like bfin-elf in that
ld -m elf32bfin is the default, and the other, bfin-linux-uclibc where
ld -m elf32bfinfd is the default. So putting bfin-*-*linux* in test
xfails or elsewhere is wrong. We want bfin-*-linux* instead to just
select the fdpic bfin target.
This patch corrects wrong bfin target triples in the ld testsuite,
not just the recent change but others I'd added to xfails too.
It also fixes the bfin-linux-uclibc ld-elf/64ksec fail
This fixes two memory leaks in the vms archive handling.
* vms-lib.c (_bfd_vms_lib_build_map): Free input symbols.
(_bfd_vms_lib_write_archive_contents): Free archive map symbols.
In test-case gdb.base/step-over-exit.exp, we set a breakpoint on _exit and
continue, expecting to hit the breakpoint.
Without glibc debug info installed, we have with target board unix/-m64:
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0x00007ffff7d46aee in \
_exit () from /lib64/libc.so.6^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
and with target board unix/-m32:
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, 0xf7d84c25 in _exit () from \
/lib/libc.so.6^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
However after installing debug info (packages glibc-debuginfo and
glibc-32bit-debuginfo), we have for -m64 (note: __GI__exit instead of _exit):
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, \
__GI__exit (status=<optimized out>) at \
../sysdeps/unix/sysv/linux/_exit.c:27^M
27 {^M
(gdb) PASS: gdb.base/step-over-exit.exp: continue to exit
...
and -m32 (note: _Exit instead of _exit):
...
Thread 2.1 "step-over-exit" hit Breakpoint 2.2, _Exit () at \
../sysdeps/unix/sysv/linux/i386/_exit.S:24^M
24 ../sysdeps/unix/sysv/linux/i386/_exit.S: No such file or directory.^M
(gdb) FAIL: gdb.base/step-over-exit.exp: continue to exit
...
The gdb_test allows for both _exit and __GI__exit, but not _Exit:
...
gdb_test "continue" \
"Continuing\\..*Breakpoint $decimal.*_exit \\(.*\\).*" \
"continue to exit"
...
Fix this by allowing _Exit as well.
Tested on x86_64-linux.
PR 30374
* ldfile.c (struct input_remap): New structure. (ldfile_add_remap): New function. (ldfile_remap_input_free): New function. (ldfile_add_remap_file): New function. (ldfile_possibly_remap_input): New function. (ldfile_print_input_remaps): New function. * ldfile.h: Add prototypes for new functions.
* ldlang.c (new_afile): Call ldfile_possibly_remap_input. (lang_finish): Call ldfile_remap_input_free. (lang_map): Call ldfile_print_input_remaps.
* ldlex.h (OPTION_REMAP_INPUTS, OPTION_REMAP_INPUTS_FILE): Define.
* lexsup.c (ld_options): Add --remap-inputs-file and --remap-inputs. (parse_args): Handle new options.
* NEWS: Mention the new feature.
* ld.texi: Document the new options.
* testsuite/ld-misc/input-remap.exp: New test driver.
* testsuite/ld-misc/remaps.r: New file: Expected linker output.
* testsuite/ld-misc/remaps.txt: New file. Input remaps file.
A number of backends want to return bfd_reloc_dangerous messaqes from
relocation special_function, and construct the message using asprintf.
Such messages are not freed anywhere, leading to small memory leaks
inside libbfd. To limit the leaks, I'd implemented a static buffer in
the ppc backends that was freed before use in asprintf output. This
patch extends that scheme to other backends using a shared static
buffer and goes further in freeing the buffer on any bfd_close.
The patch also fixes a few other cases where asprintf output was not
freed after use.
bfd/
* bfd.c (_input_error_msg): Make global and rename to..
(_bfd_error_buf): ..this.
(bfd_asprintf): New function.
(bfd_errmsg): Use bfd_asprintf.
* opncls.c (bfd_close_all_done): Free _buf_error_buf.
* elf32-arm.c (find_thumb_glue, find_arm_glue): Use bfd_asprintf.
* elf32-nios2.c (nios2_elf32_relocate_section): Likewise.
* elf32-ppc.c (ppc_elf_unhandled_reloc): Likewise.
* elf64-ppc.c (ppc64_elf_unhandled_reloc): Likewise.
* elfnn-riscv.c (riscv_resolve_pcrel_lo_relocs): Likewise.
(riscv_elf_relocate_section): Likewise.
* libbfd.h: Regenerate.
gas/
* read.c (read_end): Free current_name and current_label.
(do_s_func): Likewise on error path. strdup label.
ld/
* pe-dll.c (make_head, make_tail, make_one),
(make_singleton_name_thunk, make_import_fixup_entry),
(make_runtime_pseudo_reloc),
(pe_create_runtime_relocator_reference: Free oname after use.
When running test-case gdb.tui/long-prompt.exp with check-read1, we get:
...
(gdb) FAIL: gdb.tui/long-prompt.exp: prompt size == width + 1: \
end of screen: at last line
...
The problem is in these commands:
...
Term::command "echo \\n"
Term::command "echo \\n"
Term::command "echo \\n"
Term::command "echo \\n"
...
The last one makes the terminal scroll, and the scrolling makes the expected
output match on a different line.
Fix this by replacing the sequence with a single command:
...
Term::command "echo \\n\\n\\n\\n\\n\\n"
...
which avoids scrolling.
Tested on x86_64-linux.
There is a test-case that contains a unit test for tuiterm:
gdb.tui/tuiterm.exp.
However, this only excercises the tuiterm itself, and not the functions that
interact with it, like Term::command.
Add a new test-case gdb.tui/tuiterm-2.exp that:
- overrides proc accept_gdb_output (to be able simulate incorrect responses
while avoiding the timeout),
- overrides proc send_gdb (to be able to call Term::command without a gdb
instance, such that all tuiterm input is generated by the test-case).
- issues Term::command calls, and
- checks whether they behave correctly.
This exposes a problem in Term::command. The "prompt before command" regexp
starts with a bit that is supposed to anchor the prompt to the border:
...
set str "(^|\|)$gdb_prompt $str"
...
but that doesn't work due to insufficient escaping. Fix this by adding the
missing escape:
...
set str "(^|\\|)$gdb_prompt $str"
...
Futhermore, the "prompt after command" regexp in Term::wait_for has no
anchoring at all:
...
set prompt_wait_for "$gdb_prompt \$"
...
so add that as well.
Tested on x86_64-linux.
Currently proc with_override does not work with procs with default value args.
Fix this, and add a test-case excercising this scenario.
Tested on x86_64-linux.
On openSUSE Leap 15.4 with system python 3.6, I run into:
...
(gdb) python check_everything()^M
(gdb) FAIL: gdb.dap/type_check.exp: type checker
...
In check_everything, the hasattr test fails silently:
...
def check_everything():
# Older versions of Python can't really implement this.
if hasattr(typing, "get_origin"):
...
and that makes the gdb_test in the test-case fail.
Fix this by emitting UNSUPPORTED instead in check_everything, and detecting
this in the test-case.
Tested on x86_64-linux.
We recently realized that symbol_needs_eval_fail.exp and
symbol_needs_eval_timeout.exp invalidly dereference an int (4 bytes on
x86_64) by reading 8 bytes (the size of a pointer).
Here how it goes:
In gdb/testsuite/gdb.dwarf2/symbol_needs_eval.c a global variable is
defined:
int exec_mask = 1;
and later both tests build some DWARF using the assembler doing:
set exec_mask_var [gdb_target_symbol exec_mask]
...
DW_TAG_variable {
{DW_AT_name a}
{DW_AT_type :$int_type_label}
{DW_AT_location {
DW_OP_addr $exec_mask_var
DW_OP_deref
...
}
}
The definition of the DW_OP_deref (from Dwarf5 2.5.1.3 Stack Operations)
says that "The size of the data retrieved from the dereferenced address
is the size of an address on the target machine."
On x86_64, the size of an int is 4 while the size of an address is 8.
The result is that when evaluating this expression, the debugger reads
outside of the `a` variable.
Fix this by using `DW_OP_deref_size $int_size` instead. To achieve
this, this patch adds the necessary steps so we can figure out what
`sizeof(int)` evaluates to for the current target.
While at it, also change the definition of the int type in the assembled
DWARF information so we use the actual target's size for an int instead
of the literal 4.
Tested on x86_64 Linux.
Approved-By: Tom Tromey <tom@tromey.com>
Tom Tromey pointed out that the test and call to error() for the
DW_OP_GNU_uninit case in dwarf_expr_context::execute_stack_op (in
gdb/dwarf2/expr.c)...
if (op_ptr != op_end && *op_ptr != DW_OP_piece
&& *op_ptr != DW_OP_bit_piece)
error (_("DWARF-2 expression error: DW_OP_GNU_uninit must always "
"be the very last op in a DWARF expression or "
"DW_OP_piece/DW_OP_bit_piece piece."));
...could be replaced by a call to dwarf_expr_require_composition which
performs a similar check and outputs a suitable error message.
Currently the Fortran test suite does not run with armflang because the
compiler detection fails. This in turn means fortran_runto_main does not
know which main method to use to start a test case.
Fortran compiler detection was added in 44d469c5f85; however, the commit
message notes that it was not tested with armflang.
This commit tests and fixes up a minor issue to get the detection
working.
The goal here is to get the tests running and preventing further
regressions during future work. This change does not do anything to fix
existing failures.
>From what I can understand, the auto detection leverages the
preprocessor to extract the Fortran compiler identity from the defines.
This preprocessor output is then evaluated by the test suite to import
these defines.
In the case of armflang, this evaluation step is disrupted by the
presence of the following warning:
$ armflang -E -fdiagnostics-color=never testsuite/lib/compiler.F90 -o compiler.exp
$ clang-13: warning: argument unused during compilation: '-fdiagnostics-color=never' [-Wunused-command-line-argument]
The evaluation logic is already set up to filter this warning, but the
prefix differs.
This commit fixes the issue by updating the filter to exclude the
armflang flavour of warning.
gdb.fortran regression tests run with GNU, Intel and Intel LLVM. No
regressions detected.
The gdb.fortran test results with ACfL 23.04.1 are as follows.
Before:
# of expected passes 560
# of unexpected failures 113
# of unresolved testcases 2
# of untested testcases 5
# of duplicate test names 2
After:
# of expected passes 5388
# of unexpected failures 628
# of known failures 10
# of untested testcases 8
# of unsupported tests 5
# of duplicate test names 5
As can be seen from the above, there are now considerably more passing
assertions.
Reviewed-By: Luis Machado <luis.machado@arm.com>
Approved-By: Tom Tromey <tom@tromey.com>
Kévin pointed out that gdb claims a minimum Python version of 3.2, but
the DAP code uses f-strings, which were added in 3.6.
This patch removes the uses of f-strings from the DAP code. I can't
test an older version of Python, but I did confirm that this still
works with the version I have.
I realized that I had only implemented DAP breakpoint conditions for
exception breakpoints, and not other kinds of breakpoints. This patch
corrects the oversight.
