Make sure we error out on overflow instead of truncating in all cases.
The current implementation of parse_number contains a comment about PR16377,
but that's related to C-like languages. In absence of information of whether
the same fix is needed for pascal, take the conservative approach and keep
behaviour for decimals unchanged.
Tested on x86_64-linux, with a build with --enable-targets=all.
Make sure we error out on overflow instead of truncating in all cases.
The current implementation of parse_number contains a comment about PR16377,
but that's related to C-like languages. In absence of information of whether
the same fix is needed for go, take the conservative approach and keep
behaviour for decimals unchanged.
Tested on x86_64-linux, with a build with --enable-targets=all.
As mentioned in commit 5b758627a1 ("Make gdb.base/parse_number.exp test all
architectures"):
...
There might be a bug that 32-bit fortran truncates 64-bit values to
32-bit, given "p/x 0xffffffffffffffff" returns "0xffffffff".
...
More concretely, we have:
...
$ for arch in i386:x86-64 i386; do \
gdb -q -batch -ex "set arch $arch" -ex "set lang fortran" \
-ex "p /x 0xffffffffffffffff"; \
done
The target architecture is set to "i386:x86-64".
$1 = 0xffffffffffffffff
The target architecture is set to "i386".
$1 = 0xffffffff
...
Fix this by adding a range check in parse_number in gdb/f-exp.y.
Furthermore, make sure we error out on overflow instead of truncating in all
other cases.
Tested on x86_64-linux.
[ Assuming arch i386:x86-64, sizeof (int) == 4,
sizeof (long) == sizeof (long long) == 8. ]
Currently we have (decimal for 0x80000000):
...
(gdb) ptype 2147483648
type = unsigned int
...
According to C language rules, unsigned types cannot be used for decimal
constants, so the type should be long instead (reported in PR16377).
Fix this by making sure the type of 2147483648 is long.
The next interesting case is (decimal for 0x8000000000000000):
...
(gdb) ptype 9223372036854775808
type = unsigned long
...
According to the same rules, unsigned long is incorrect.
Current gcc uses __int128 as type, which is allowed, but we don't have that
available in gdb, so the strict response here would be erroring out with
overflow.
Older gcc without __int128 support, as well as clang use an unsigned type, but with
a warning. Interestingly, clang uses "unsigned long long" while gcc uses
"unsigned long", which seems the better choice.
Given that the compilers allow this as a convience, do the same in gdb
and keep type "unsigned long", and make this explicit in parser and test-case.
Furthermore, make sure we error out on overflow instead of truncating in all
cases.
Tested on x86_64-linux with --enable-targets=all.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16377
Currently we only test value 0xffffffffffffffff in test-case
gdb.base/parse_numbers.exp.
Test more interesting values, both in decimal and hex format, as well as
negative decimals for language modula-2.
This results in an increase in total tests from 15572 to 847448 (55 times
more tests).
Balance out the increase in runtime by reducing the number of architectures
tested: only test one architecture per sizeof longlong/long/int/short
combination, while keeping the possibility intact to run with all
architectures (through setting a variable in the test-case)
Results in slight reduction of total tests: 15572 -> 13853.
Document interesting cases in the expected results:
- wrapping from unsigned to signed
- truncation
- PR16377: using unsigned types to represent decimal constants in C
Running the test-case with a gdb build with -fsanitize=undefined, we trigger
two UB errors in the modula-2 parser, filed as PR29163.
Tested on x86_64-linux with --enable-targets=all.
On openSUSE Tumbleweed (with gcc-12, enabling ctf tests) I run into:
...
ERROR: tcl error sourcing src/gdb/testsuite/gdb.ctf/funcreturn.exp.
ERROR: tcl error code NONE
ERROR: Unexpected arguments: \
{print v_double_func} \
{[0-9]+ = {double \(\)} 0x[0-9a-z]+.*} \
{print double function} \
}
...
The problem is a curly brace as fourth argument to gdb_test, which errors out
due to recently introduced more strict argument checking in gdb_test.
Fix the error by removing the brace.
Though this fixes the error for me, due to PR29160 I get only FAILs, so I can't
claim proper testing on x86_64-linux.
When running test-case gdb.threads/manythreads.exp with check-read1, I ran
into this hard-to-reproduce FAIL:
...
[New Thread 0x7ffff7318700 (LWP 31125)]^M
[Thread 0x7ffff7321700 (LWP 31124) exited]^M
[New T^C^M
^M
Thread 769 "manythreads" received signal SIGINT, Interrupt.^M
[Switching to Thread 0x7ffff6d66700 (LWP 31287)]^M
0x00007ffff7586a81 in clone () from /lib64/libc.so.6^M
(gdb) FAIL: gdb.threads/manythreads.exp: stop threads 1
...
The matching in the failing gdb_test_multiple is done in an intricate way,
trying to pass on some order and fail on another order.
Fix this by rewriting the regexps to match one line at most, and detecting
invalid order by setting and checking state variables.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29177
When running selftest print_one_insn::ez80-adl we run into this warning:
...
Running selftest print_one_insn::ez80-adl.
warning: Unable to determine inferior's software breakpoint type: couldn't
find `_break_handler' function in inferior. Will be used default software \
breakpoint instruction RST 0x08.
...
Fix this by explicitly handling bfd_arch_z80 in print_one_insn_test.
Tested on x86_64-linux.
When running the selftests, I run into:
...
$ gdb -q -batch -ex "maint selftest"
...
Running selftest execute_cfa_program::aarch64:ilp32.
warning: A handler for the OS ABI "GNU/Linux" is not built into this
configuration of GDB. Attempting to continue with the default aarch64:ilp32
settings.
...
and likewise for execute_cfa_program::i8086 and
execute_cfa_program::ia64-elf32.
The warning can easily be reproduced outside the selftests by doing:
...
$ gdb -q -batch -ex "set arch aarch64:ilp32"
...
and can be prevented by first doing "set osabi none".
Fix the warning by setting osabi to none while doing selftests that iterate
over all architectures.
This causes a regression in the print_one_insn selftests for the ARC
architecture.
The problem is pre-existing, and can be demonstrated (already without this
patch) using:
...
$ gdb -q -batch -ex "set osabi none" -ex "maint selftest print_one_insn::A6"
Running selftest print_one_insn::A6.
Self test failed: Cannot access memory at address 0x0
Ran 1 unit tests, 1 failed
$
...
For ARC, we use the generic case in print_one_insn_test, containing this code:
...
int kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc);
...
insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen);
...
The problem is that with osabi linux we trigger:
...
static int
arc_linux_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr)
{
return trap_size;
}
...
but with osabi none:
...
arc_breakpoint_kind_from_pc (struct gdbarch *gdbarch, CORE_ADDR *pcptr)
{
size_t length_with_limm = gdb_insn_length (gdbarch, *pcptr);
...
which needs access to memory, and will consequently fail.
Fix this in print_one_insn_test, in the default case, by iterating over
supported osabi's to makes sure we trigger arc_linux_breakpoint_kind_from_pc
which will give us a usable instruction to disassemble.
Tested on x86_64-linux.
This reverts commit fc18b1c5af ("[gdb] Fix warning in foreach_arch
selftests").
The commit introduced regressions for an --enable-targets=all build:
...
Running selftest print_one_insn::A6.^M
Self test failed: Cannot access memory at address 0x0^M
...
and while investigating those I realized that the commit fc18b1c5af
complicates things by trying to set the current osabi.
So, revert the patch in preparation for a simpler solution.
Tested on x86_64-linux.
Don't use gregset.h in *-tdep.c since it's not usable on
hosts that don't have <sys/procfs.h>. It's not needed by
this file, and should only be needed by *-nat.c files.
Similarly for the elf mips support.
* elf32-mips.c (mips_elf_final_gp): Don't segfault on symbols
in any of the bfd_is_const_section sections.
* elf64-mips.c (mips_elf64_final_gp): Likewise.
* elfn32-mips.c (mips_elf_final_gp): Likewise.
Not just the undefined section has a NULL owner, the absolute section
has too. Which means we can't find output_bfd for __gp. Also, may as
well test directly for output_bfd == NULL.
* coff-mips.c (mips_gprel_reloc): Don't segfault on any of
bfd_is_const_section sections.
On openSUSE Tumbleweed with target board unix/-m32, I run into:
...
PASS: gdb.mi/mi-var-block.exp: step at do_block_test 2
Expecting: ^(-var-update \*[^M
]+)?(\^done,changelist=\[{name="foo",in_scope="true",type_changed="false",has_more="0"},
{name="cb",in_scope="true",type_changed="false",has_more="0"}\][^M
]+[(]gdb[)] ^M
[ ]*)
-var-update *^M
^done,changelist=[{name="foo",in_scope="true",type_changed="false",has_more="0"}]^M
(gdb) ^M
FAIL: gdb.mi/mi-var-block.exp: update all vars: cb foo changed (unexpected output)
...
The problem is that the test-case attempts to detect a change in the cb
variable caused by this initialization:
...
void
do_block_tests ()
{
int cb = 12;
...
but that only works if the stack location happens to be unequal to 12 before
the initialization.
Fix this by first initializing to 0, and then changing the value to 12:
...
- int cb = 12;
+ int cb = 0;
+ cb = 12;
...
and detecting that change.
Tested on x86_64-linux.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29195
"main" is redeclared with a different type in maint.c. I think this
might have come from my first gdb patch, many many years ago. While I
wonder if this profiling code is actually useful at all any more, in
the meantime it's simple to fix the declaration.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
"struct insn_decode_record_t" is defined in multiple .c files, causing
ODR warnings. This patch renames the types, and removes the use of
"typedef" here -- this is a C-ism that's no longer needed.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
observable.h triggers an ODR warning because this line:
extern observable<struct target_ops */* target */> target_changed;
... may be the only declaration of "struct target_ops" in scope
(depending on the particular .c file) -- and this declares it in a
namespace, resulting in confusion.
This patch fixes the problem by adding a forward declaration.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=22395
When execute the following command on LoongArch:
make check-gdb TESTS="gdb.base/branch-to-self.exp"
there exist the following failed testcases:
FAIL: gdb.base/branch-to-self.exp: single-step: si (timeout)
FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: continue to breakpoint: continue to break (timeout)
FAIL: gdb.base/branch-to-self.exp: break-cond: side=host: p counter (timeout)
Implement the software_single_step gdbarch method to decode the current
branch instruction and determine the address of the next instruction on
LoongArch to fix the above failed testcases.
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
From: Ulrich Weigand <ulrich.weigand@de.ibm.com>
build_objfile_section_table () creates four synthetic sections per
objfile, which are collected by update_section_map () and passed to
std::sort (). When there are a lot of objfiles, for example, when
debugging JITs, the presence of these sections slows down the sorting
significantly.
The output of update_section_map () is used by find_pc_section (),
which can never return any of these sections: their size is 0, so they
cannot be accepted by bsearch_cmp ().
Filter them (and all the other empty sections) out in
insert_section_p (), which is used only by update_section_map ().
Fix Cygwin build after 0578e87f ("Remove some globals from
nat/windows-nat.c"). Update code under ifdef __CYGWIN__ for globals
moved to members of struct windows_process_info.
Fix Cygwin build after fcab5839 ("Implement pid_to_exec_file for Windows
in gdbserver"). That change moves code from gdb/windows-nat.c to
gdb/nat/windows-nat.c, but doesn't add the required typedefs and
includes for parts of that code under ifdef __CYGWIN__.
Fix the signed overflows by using unsigned variables and detect
overflow at BUG! comment.
* atof-generic.c (atof_generic): Avoid signed integer overflow.
Return ERROR_EXPONENT_OVERFLOW if exponent overflows a long.
This fixes some horrible code using do_scrub_chars. What we had ran
text through do_scrub_chars twice, directly in read_a_source_file and
again via the input_scrub_include_sb call. That's silly, and since
do_scrub_chars is a state machine, possibly wrong. More silliness is
evident in the temporary malloc'd buffer for do_scrub_chars output,
which should have been written directly to sbuf.
So, get rid of the do_scrub_chars call and support functions, leaving
scrubbing to input_scrub_include_sb. I did wonder about #NO_APP
overlapping input_scrub_next_buffer buffers, but that should only
happen if the string starts in one file and finishes in another.
* read.c (scrub_string, scrub_string_end): Delete.
(scrub_from_string): Delete.
(read_a_source_file): Rewrite #APP processing.
It is possible for sb_scrub_and_add_sb to not consume all of the input
string buffer. If this happens for reasons explained in the comment,
do_scrub_chars can leave pointers to the string buffer for the next
call. This patch fixes that by ensuring the input is drained. Note
that the behaviour for an empty string buffer is also changed,
avoiding another do_scrub_chars bug where empty input and single char
sized output buffers could result in a write past the end of the
output.
sb.c (sb_scrub_and_add_sb): Loop until all of input sb is
consumed.
Since commit b43771b045 it has been possible to look up addresses
that match a unit with errors, since ranges are added to a trie while
the unit is being parsed. On error, parse_comp_unit leaves
first_child_die_ptr NULL which results in a NULL info_ptr being passed
to scan_unit_for_symbols. Fix this by setting unit->error.
Also wrap some overlong lines, and fix some formatting errors.
* dwarf2.c: Formatting.
(parse_comp_unit): Set unit->error on err_exit path.
