I was always a bit confused by next_adapter, because it kind of mixes
the element type and the iterator type. In reality, it is not much more
than a class that wraps two iterators (begin and end). However, it
assumes that:
- you can construct the begin iterator by passing a pointer to the
first element of the iterable
- you can default-construct iterator to make the end iterator
I think that by generalizing it a little bit, we can re-use it at more
places.
Rename it to "iterator_range". I think it describes a bit better: it's
a range made by wrapping a begin and end iterator. Move it to its own
file, since it's not related to next_iterator anymore.
iterator_range has two constructors. The variadic one, where arguments
are forwarded to construct the underlying begin iterator. The end
iterator is constructed through default construction. This is a
generalization of what we have today.
There is another constructor which receives already constructed begin
and end iterators, useful if the end iterator can't be obtained by
default-construction. Or, if you wanted to make a range that does not
end at the end of the container, you could pass any iterator as the
"end".
This generalization allows removing some "range" classes, like
all_inferiors_range. These classes existed only to pass some arguments
when constructing the begin iterator. With iterator_range, those same
arguments are passed to the iterator_range constructed and then
forwarded to the constructed begin iterator.
There is a small functional difference in how iterator_range works
compared to next_adapter. next_adapter stored the pointer it received
as argument and constructeur an iterator in the `begin` method.
iterator_range constructs the begin iterator and stores it as a member.
Its `begin` method returns a copy of that iterator.
With just iterator_range, uses of next_adapter<foo> would be replaced
with:
using foo_iterator = next_iterator<foo>;
using foo_range = iterator_range<foo_iterator>;
However, I added a `next_range` wrapper as a direct replacement for
next_adapter<foo>. IMO, next_range is a slightly better name than
next_adapter.
The rest of the changes are applications of this new class.
Simon Marchi [Tue, 22 Jun 2021 18:11:32 +0000 (14:11 -0400)]
gdb/testsuite: restore configure script
Commit f99d1d37496f ("Remove gdb/testsuite/configure") removed
gdb/testsuite/configure, as anything gdb/testsuite/configure did could
be done by gdb/configure.
There is however one use case that popped up when this changed
propagated to downstream consumers, to run the testsuite on an already
built GDB. In the workflow of ROCm-GDB at AMD, a GDB package is built
in a CI job. This GDB package is then tested on different machines /
hardware configurations as part of other CI jobs. To achieve this,
those CI jobs only configure the testsuite directory and run "make
check" with an appropriate board file.
In light of this use case, the way I see it is that gdb/testsuite could
be considered its own project. It could be stored in a completely
different repo if we want to, it just happens to be stored inside gdb/.
Since the only downside of having gdb/testsuite/configure is that it
takes a few more seconds to run, but on the other hand it's quite useful
for some people, I propose re-adding it.
In a sense, this is revert of f99d1d37496f, but it's not a direct
git-revert, as some things have changed since.
gdb/ChangeLog:
* configure.ac: Remove things that were moved from
testsuite/configure.ac.
* configure: Re-generate.
Joel Brobecker [Sat, 3 Jul 2021 23:29:08 +0000 (16:29 -0700)]
Rename gdb/ChangeLog to gdb/ChangeLog-2021
Now that ChangeLog entries are no longer used for GDB patches,
this commit renames the file gdb/ChangeLog to gdb/ChangeLog-2021,
similar to what we would do in the context of the "Start of New
Year" procedure.
The purpose of this change is to avoid people merging ChangeLog
entries by mistake when applying existing commits that they are
currently working on.
Dan Streetman [Tue, 11 May 2021 13:28:15 +0000 (09:28 -0400)]
sim: ppc: add missing empty targets
These are copied from sim/common/Make-common.in.
On ppc the build fails without at least the 'info' target, e.g.:
Making info in ppc
make[4]: Entering directory '/<<BUILDDIR>>/gdb-10.2.2974.g5b45e89f56d+21.10.20210510155809/build/default/sim/ppc'
make[4]: *** No rule to make target 'info'. Stop.
Michael Matz [Mon, 28 Jun 2021 15:57:17 +0000 (17:57 +0200)]
elf/riscv: Fix relaxation with aliases [PR28021]
the fix for PR22756 only changed behaviour for hidden aliases,
but the same situation exists for non-hidden aliases: sym_hashes[]
can contain multiple entries pointing to the same symbol structure
leading to relaxation adjustment to be applied twice.
Fix this by testing for duplicates for everything that looks like it
has a version.
PR ld/28021
bfd/
* elfnn-riscv.c (riscv_relax_delete_bytes): Check for any
versioning.
ld/
* testsuite/ld-riscv-elf/relax-twice.ver: New.
* testsuite/ld-riscv-elf/relax-twice-1.s: New.
* testsuite/ld-riscv-elf/relax-twice-2.s: New.
* testsuite/ld-riscv-elf/ld-riscv-elf.exp
(run_relax_twice_test): New, and call it.
Pedro Alves [Thu, 3 Jun 2021 13:59:54 +0000 (09:59 -0400)]
Update gdb performance testsuite to be compatible with Python 3.8
Running "make check-perf" on a system with Python 3.8 (e.g., Ubuntu
20.04) runs into this Python problem:
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run
self.execute_test()
File "<string>", line 35, in execute_test
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure
m.start(id)
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start
self.start_time = time.clock()
AttributeError: module 'time' has no attribute 'clock'
Error while executing Python code.
(gdb) FAIL: gdb.perf/single-step.exp: python SingleStep(1000).run()
... many times over.
The problem is that the testsuite is using time.clock(), deprecated in
Python 3.3 and finaly removed in Python 3.8. The guidelines say to
use time.perf_counter() or time.process_time() instead depending on
requirements. Looking at the current description of those functions,
at:
https://docs.python.org/3.10/library/time.html
we have:
time.perf_counter() -> float
Return the value (in fractional seconds) of a performance
counter, i.e. a clock with the highest available resolution to
measure a short duration. It does include time elapsed during
sleep and is system-wide. (...)
time.process_time() -> float
Return the value (in fractional seconds) of the sum of the
system and user CPU time of the current process. It does not
include time elapsed during sleep. It is process-wide by
definition. (...)
I'm thinking that it's just best to record both instead of picking
one. So this patch replaces the MeasurementCpuTime measurement class
with two new classes -- MeasurementPerfCounter and
MeasurementProcessTime. Correspondingly, this changes the reports in
testsuite/perftest.log -- we have two new "perf_counter" and
"process_time" measurements and the "cpu_time" measurement is gone. I
don't suppose breaking backward compatibility here is a big problem.
I suspect no one is really tracking long term performance using the
perf testsuite today. And if they are, it shouldn't be hard to adjust.
For backward compatility, with Python < 3.3, both perf_counter and
process_time use the old time.clock.
gdb/testsuite/ChangeLog:
yyyy-mm-dd Qingchuan Shi <qingchuan.shi@amd.com>
Pedro Alves <pedro@palves.net>
* gdb.perf/lib/perftest/perftest.py: Import sys.
(time.perf_counter, time.process_time): Map to time.clock on
Python < 3.3.
(MeasurementCpuTime): Delete, replaced by...
(MeasurementPerfCounter, MeasurementProcessTime): .. these two new
classes.
* gdb.perf/lib/perftest/perftest.py: Import MeasurementPerfCounter
and MeasurementProcessTime instead of MeasurementCpuTime.
(TestCaseWithBasicMeasurements): Use MeasurementPerfCounter and
MeasurementProcessTime instead of MeasurementCpuTime.
Co-authored-by: Qingchuan Shi <qingchuan.shi@amd.com>
Change-Id: Ia850c05d5ce57d2dada70ba5b0061f566444aa2b
Pedro Alves [Fri, 18 Jun 2021 12:50:45 +0000 (13:50 +0100)]
gdb.perf/: FAIL on Python errors, avoid "ERROR: internal buffer is full"
Currently, if you run make check-perf on a system with Python 3.8,
tests seen to PASS, but they actually test a lot less than intended,
due to:
PerfTest::assemble, run ...
python BackTrace(64).run()
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/perftest.py", line 65, in run
self.execute_test()
File "<string>", line 49, in execute_test
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 45, in measure
m.start(id)
File "/home/pedro/rocm/gdb/src/gdb/testsuite/gdb.perf/lib/perftest/measure.py", line 102, in start
self.start_time = time.clock()
AttributeError: module 'time' has no attribute 'clock'
Error while executing Python code.
(gdb) PASS: gdb.perf/backtrace.exp: python BackTrace(64).run()
And then, after fixing the above Python compatibility issues (which
will be a separate patch), I get 86 instances of overflowing expect's
buffer, like:
ERROR: internal buffer is full.
UNRESOLVED: gdb.perf/single-step.exp: python SingleStep(1000).run()
This patch fixes both problems by adding & using a gdb_test_python_run
routine that:
- checks for Python errors
- consumes output line by line
gdb/testsuite/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* gdb.perf/backtrace.exp: Use gdb_test_python_run.
* gdb.perf/disassemble.exp: Use gdb_test_python_run.
* gdb.perf/single-step.exp: Use gdb_test_python_run.
* gdb.perf/skip-command.exp: Use gdb_test_python_run.
* gdb.perf/skip-prologue.exp: Use gdb_test_python_run.
* gdb.perf/solib.exp: Use gdb_test_python_run.
* gdb.perf/template-breakpoints.exp: Use gdb_test_python_run.
* lib/perftest.exp (gdb_test_python_run): New.
Tom de Vries [Tue, 6 Jul 2021 10:05:37 +0000 (12:05 +0200)]
[gdb/testsuite] Remove read1 timeout factor from gdb.base/info-macros.exp
At the moment some check-read1 timeouts are handled like this in
gdb.base/info-macros.exp:
...
gdb_test_multiple_with_read1_timeout_factor 10 "$test" $testname {
-re "$r1$r2$r3" {
pass $testname
}
-re ".*#define TWO.*\r\n$gdb_prompt" {
fail $testname
}
-re ".*#define THREE.*\r\n$gdb_prompt" {
fail $testname
}
-re ".*#define FOUR.*\r\n$gdb_prompt" {
fail $testname
}
}
...
which is not ideal.
We could use gdb_test_lines, but it currently doesn't support verifying
the absence of regexps, which is done using the clauses above calling fail.
Fix this by using gdb_test_lines and adding a -re-not syntax to
gdb_test_lines, such that we can do:
...
gdb_test_lines $test $testname $r1.*$r2 \
-re-not "#define TWO" \
-re-not "#define THREE" \
-re-not "#define FOUR"
...
Tested on x86_64-linux, whith make targets check and check-read1.
Also observed that check-read1 execution time is reduced from 6m35s to 13s.
gdb/testsuite/ChangeLog:
2021-07-06 Tom de Vries <tdevries@suse.de>
* gdb.base/info-macros.exp: Replace use of
gdb_test_multiple_with_read1_timeout_factor with gdb_test_lines.
(gdb_test_multiple_with_read1_timeout_factor): Remove.
* lib/gdb.exp (gdb_test_lines): Add handling or -re-not <regexp>.
Nelson Chu [Tue, 6 Jul 2021 09:27:22 +0000 (17:27 +0800)]
RISC-V: Fix the build broken with -Werror.
ChangeLog:
bfd/
* elfnn-riscv.c(riscv_elf_additional_program_headers): Removed the
unused variable s.
(riscv_elf_modify_segment_map): Added ATTRIBUTE_UNUSED for the
unused parameter info.
Tom de Vries [Tue, 6 Jul 2021 08:58:43 +0000 (10:58 +0200)]
[gdb/symtab] Fix skipping of import of C++ CU
Tom Tromey observed that when changing the language in
gdb.dwarf2/imported-unit-bp.exp from c to c++, the test failed.
This is due to this code in process_imported_unit_die:
...
/* We're importing a C++ compilation unit with tag DW_TAG_compile_unit
into another compilation unit, at root level. Regard this as a hint,
and ignore it. */
if (die->parent && die->parent->parent == NULL
&& per_cu->unit_type == DW_UT_compile
&& per_cu->lang == language_cplus)
return;
...
which should have a partial symtabs counterpart.
Add the missing counterpart in process_psymtab_comp_unit.
Tested on x86_64-linux (openSUSE Leap 15.2), no regressions for config:
- using default gcc version 7.5.0
(with 5 unexpected FAILs)
- gcc 10.3.0 and target board
unix/-flto/-O0/-flto-partition=none/-ffat-lto-objects
(with 1000 unexpected FAILs)
gdb/ChangeLog:
2021-07-06 Tom de Vries <tdevries@suse.de>
* dwarf2/read.c (scan_partial_symbols): Skip top-level imports of
c++ CU.
* testsuite/gdb.dwarf2/imported-unit-bp.exp: Moved to ...
* testsuite/gdb.dwarf2/imported-unit-bp.exp.tcl: ... here.
* testsuite/gdb.dwarf2/imported-unit-bp-c++.exp: New test.
* testsuite/gdb.dwarf2/imported-unit-bp-c.exp: New test.
* testsuite/gdb.dwarf2/imported-unit.exp: Update.
Tom Tromey [Sat, 29 May 2021 13:25:57 +0000 (07:25 -0600)]
Simplify debug_names index writing
This changes the .debug_names writer to find the TU indices in the
main loop over all CUs and TUs. (An earlier patch applied this same
treatment to the .gdb_index writer.)
Tom Tromey [Fri, 28 May 2021 22:25:32 +0000 (16:25 -0600)]
Simplify gdb_index writing
write_gdbindex writes the CUs first, then walks the signatured type
hash table to write out the TUs. However, now that CUs and TUs are
unified in the DWARF reader, it's simpler to handle both of these in
the same loop.
Tom Tromey [Fri, 28 May 2021 22:20:03 +0000 (16:20 -0600)]
Fix oddity in write_gdbindex
My recent patch to unify CUs and TUs introduced an oddity in
write_gdbindex. Here, we pass 'i' to recursively_write_psymbols, but
we must instead pass 'counter', to handle the situation where a TU is
mixed in with the CUs.
I am not sure a test case for this is possible. I think it can only
happen when using DWARF 5, where a TU appears in .debug_info.
However, this situation is already not handled correctly by
.gdb_index. I filed a bug about this.
H.J. Lu [Fri, 2 Jul 2021 20:42:32 +0000 (13:42 -0700)]
ld: Cache and reuse the IR archive file descriptor
Linker plugin_object_p opens the IR archive for each IR archive member.
For GCC plugin, plugin_object_p closes the archive file descriptor. But
for LLVM plugin, the archive file descriptor remains open. If there are
3000 IR archive members, there are 3000 file descriptors for them. We
can run out of file descriptors petty easily.
1. Add archive_plugin_fd and archive_plugin_fd_open_count to bfd so that
we can cache and reuse the IR archive file descriptor for all IR archive
members in the archive.
2. Add bfd_plugin_close_file_descriptor to properly close the IR archive
file descriptor.
bfd/
PR ld/28040
* archive.c (_bfd_archive_close_and_cleanup): Close the archive
plugin file descriptor if needed.
* bfd.c (bfd): Add archive_plugin_fd and
archive_plugin_fd_open_count.
* opncls.c (_bfd_new_bfd): Initialize to -1.
* plugin.c (bfd_plugin_open_input): Cache and reuse the archive
plugin file descriptor.
(bfd_plugin_close_file_descriptor): New function.
(try_claim): Call bfd_plugin_close_file_descriptor.
* plugin.h (bfd_plugin_close_file_descriptor): New.
* bfd-in2.h: Regenerated.
ld/
PR ld/28040
* plugin.c (plugin_input_file): Add ibfd.
(release_plugin_file_descriptor): New function.
(release_input_file): Call release_plugin_file_descriptor to
close input->fd.
(plugin_object_p): Call release_plugin_file_descriptor to close
input->fd. Also call release_plugin_file_descriptor if not
claimed.
* testsuite/config/default.exp (RANLIB): New.
* testsuite/ld-plugin/lto.exp: Run ranlib test.
This commit has not yet been applied to the master sources in the gcc repository.
It was submitted here: https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574405.html
The commit allows options to be set for the AR and RANLIB programs used when building libiberty, which in turn allows building with LTO enabled.
Tom de Vries [Mon, 5 Jul 2021 14:26:42 +0000 (16:26 +0200)]
[gdb/testsuite] Fix fail in gdb.fortran/ptype-on-functions.exp with gcc-7
Since commit 05b85772061 "gdb/fortran: Add type info of formal parameter for
clang" I see:
...
(gdb) ptype say_string^M
type = void (character*(*), integer(kind=4))^M
(gdb) FAIL: gdb.fortran/ptype-on-functions.exp: ptype say_string
...
The part of the commit causing the fail is:
...
gdb_test "ptype say_string" \
- "type = void \\(character\\*\\(\\*\\), integer\\(kind=\\d+\\)\\)"
+ "type = void \\(character\[^,\]+, $integer8\\)"
...
which fails to take into account that for gcc-7 and before, the type for
string length of a string argument is int, not size_t.
Fix this by allowing both $integer8 and $integer4.
Tested on x86_64-linux, with gcc-7 and gcc-10.
gdb/testsuite/ChangeLog:
2021-07-05 Tom de Vries <tdevries@suse.de>
* gdb.fortran/ptype-on-functions.exp: Allow both $integer8 and
$integer4 for size of string length.
Simon Marchi [Sun, 27 Jun 2021 19:13:14 +0000 (15:13 -0400)]
gdb: fall back on sigpending + sigwait if sigtimedwait is not available
The macOS platform does not provide sigtimedwait, so we get:
CXX compile/compile.o
In file included from /Users/smarchi/src/binutils-gdb/gdb/compile/compile.c:46:
/Users/smarchi/src/binutils-gdb/gdb/../gdbsupport/scoped_ignore_signal.h:69:4: error: use of undeclared identifier 'sigtimedwait'
sigtimedwait (&set, nullptr, &zero_timeout);
^
An alternative to sigtimedwait with a timeout of 0 is to use sigpending,
to first check which signals are pending, and then sigwait, to consume
them. Since that's slightly more expensive (2 syscalls instead of 1),
keep using sigtimedwait for the platforms that provide it, and fall back
to sigpending + sigwait for the others.
gdbsupport/ChangeLog:
* scoped_ignore_signal.h (struct scoped_ignore_signal)
<~scoped_ignore_signal>: Use sigtimedwait if HAVE_SIGTIMEDWAIT
is defined, else use sigpending + sigwait.
Change-Id: I2a72798337e81dd1bbd21214736a139dd350af87 Co-Authored-By: John Baldwin <jhb@FreeBSD.org>
Alan Modra [Sat, 3 Jul 2021 02:09:24 +0000 (11:39 +0930)]
Re: opcodes: constify & local meps macros
Commit f375d32b35ce changed a generated file. Edit the source instead.
* mep.opc (macros): Make static and const.
(lookup_macro): Return and use const pointer.
(expand_macro): Make mac param const.
(expand_string): Make pmacro const.
Alan Modra [Mon, 5 Jul 2021 07:01:30 +0000 (16:31 +0930)]
PR28055, segfault in bpf special reloc function
The testcase in this PR tickled two bugs fixed here. output_bfd is
NULL when a reloc special_function is called for final linking and
when called from bfd_generic_get_relocated_section_contents. Clearly
using output_bfd is wrong as it results in segfaults. Not only that,
the endianness of the reloc field really should be that of the input.
The second bug was not checking that the entire reloc field was
contained in the section contents.
PR 28055
* elf64-bpf.c (bpf_elf_generic_reloc): Use correct bfd for bfd_put
and bfd_put_32 calls. Correct section limit checks.
Alan Modra [Sat, 3 Jul 2021 00:08:40 +0000 (09:38 +0930)]
PR28047, readelf crash due to assertion failure
DW_FORM_ref1, DW_FORM_ref2, DW_FORM_ref4, DW_FORM_ref1, and
DW_FORM_ref_udata are all supposed to be within the containing unit.
PR 28047
* dwarf.c (get_type_abbrev_from_form): Add cu_end parameter.
Check DW_FORM_ref1 etc. arg against cu_end rather than end of
section. Adjust all callers.
Simon Marchi [Sun, 27 Jun 2021 03:31:24 +0000 (23:31 -0400)]
gdb: return early if no execution in darwin_solib_create_inferior_hook
When loading a file using the file command on macOS, we get:
$ ./gdb -nx --data-directory=data-directory -q -ex "file ./test"
Reading symbols from ./test...
Reading symbols from /Users/smarchi/build/binutils-gdb/gdb/test.dSYM/Contents/Resources/DWARF/test...
/Users/smarchi/src/binutils-gdb/gdb/thread.c:72: internal-error: struct thread_info *inferior_thread(): Assertion `current_thread_ != nullptr' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
The backtrace is:
* frame #0: 0x0000000101fcb826 gdb`internal_error(file="/Users/smarchi/src/binutils-gdb/gdb/thread.c", line=72, fmt="%s: Assertion `%s' failed.") at errors.cc:52:3
frame #1: 0x00000001018a2584 gdb`inferior_thread() at thread.c:72:3
frame #2: 0x0000000101469c09 gdb`get_current_regcache() at regcache.c:421:31
frame #3: 0x00000001015f9812 gdb`darwin_solib_get_all_image_info_addr_at_init(info=0x0000603000006d00) at solib-darwin.c:464:34
frame #4: 0x00000001015f7a04 gdb`darwin_solib_create_inferior_hook(from_tty=1) at solib-darwin.c:515:5
frame #5: 0x000000010161205e gdb`solib_create_inferior_hook(from_tty=1) at solib.c:1200:3
frame #6: 0x00000001016d8f76 gdb`symbol_file_command(args="./test", from_tty=1) at symfile.c:1650:7
frame #7: 0x0000000100abab17 gdb`file_command(arg="./test", from_tty=1) at exec.c:555:3
frame #8: 0x00000001004dc799 gdb`do_const_cfunc(c=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:102:3
frame #9: 0x00000001004ea042 gdb`cmd_func(cmd=0x000061100000c340, args="./test", from_tty=1) at cli-decode.c:2160:7
frame #10: 0x00000001018d4f59 gdb`execute_command(p="t", from_tty=1) at top.c:674:2
frame #11: 0x0000000100eee430 gdb`catch_command_errors(command=(gdb`execute_command(char const*, int) at top.c:561), arg="file ./test", from_tty=1, do_bp_actions=true)(char const*, int), char const*, int, bool) at main.c:523:7
frame #12: 0x0000000100eee902 gdb`execute_cmdargs(cmdarg_vec=0x00007ffeefbfeba0 size=1, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x00007ffeefbfec20) at main.c:618:9
frame #13: 0x0000000100eed3a4 gdb`captured_main_1(context=0x00007ffeefbff780) at main.c:1322:3
frame #14: 0x0000000100ee810d gdb`captured_main(data=0x00007ffeefbff780) at main.c:1343:3
frame #15: 0x0000000100ee8025 gdb`gdb_main(args=0x00007ffeefbff780) at main.c:1368:7
frame #16: 0x00000001000044f1 gdb`main(argc=6, argv=0x00007ffeefbff8a0) at gdb.c:32:10
frame #17: 0x00007fff20558f5d libdyld.dylib`start + 1
The solib_create_inferior_hook call in symbol_file_command was added by
commit ea142fbfc9c1 ("Fix breakpoints on file reloads for PIE
binaries"). It causes solib_create_inferior_hook to be called while
the inferior is not running, which darwin_solib_create_inferior_hook
does not expect. darwin_solib_get_all_image_info_addr_at_init, in
particular, assumes that there is a current thread, as it tries to get
the current thread's regcache.
Fix it by adding a target_has_execution check and returning early. Note
that there is a similar check in svr4_solib_create_inferior_hook.
gdb/ChangeLog:
* solib-darwin.c (darwin_solib_create_inferior_hook): Return
early if no execution.
Tom Tromey [Sat, 3 Jul 2021 17:40:54 +0000 (11:40 -0600)]
Use 'bool' more idiomatically in dwarf_decode_lines
I noticed a couple of spots related to dwarf_decode_lines where the
'include_p' field was not being used idiomatically -- it is of type
bool now, so treat it as such.
gdb/ChangeLog
2021-07-03 Tom Tromey <tom@tromey.com>
* dwarf2/read.c (lnp_state_machine::record_line): Use 'true'.
(dwarf_decode_lines): Remove '=='.
Pedro Alves [Fri, 4 Jun 2021 16:12:41 +0000 (17:12 +0100)]
Document TUI improvements in the manual & NEWS
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
Hannes Domani <ssbssa@yahoo.de>
* NEWS: Add new "TUI Improvements" section and mention mouse
support and that unrecognized special keys are now passed to
GDB. Mention Python Window.click in the Python improvements
section.
gdb/doc/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
* gdb.texinfo (TUI): <TUI Mouse Support>: New node/section.
Co-Authored-By: Hannes Domani <ssbssa@yahoo.de>
Change-Id: I0d79a795d8ac561fd28cdc5184bff029ba28bc64
Alan Modra [Fri, 2 Jul 2021 07:57:31 +0000 (17:27 +0930)]
Re: Fix minor NDS32 renaming snafu
Some extern declarations differ in constnes to their definitions too.
Let's make sure this sort of thing doesn't happen again, but putting
the externs in a header where they belong.
gas/
* config/tc-nds32.c (nds32_keyword_gpr): Don't declare.
(md_begin): Constify k.
opcodes/
* nds32-dis.c (nds32_find_reg_keyword): Constify arg and return.
(nds32_parse_audio_ext, nds32_parse_opcode): Constify psys_reg.
(nds32_field_table, nds32_opcode_table, nds32_keyword_table),
(nds32_opcodes, nds32_operand_fields, nds32_keywords),
(nds32_keyword_gpr): Move declarations to..
* nds32-asm.h: ..here, constifying to match definitions.
Mike Frysinger [Thu, 1 Jul 2021 04:28:10 +0000 (00:28 -0400)]
sim: m32r: unify ELF & Linux traps logic
This makes the simulator work the same regardless of the target (bare
metal m32r-elf or Linux m32r-linux-gnu) by unifying the traps code.
It was mostly already the same with the only difference being support
for trap #2 reserved for Linux syscalls. We can move that logic to
runtime by checking the current environment operating mode instead.
Mike Frysinger [Thu, 1 Jul 2021 04:17:38 +0000 (00:17 -0400)]
sim: m32r: replace custom endian helpers with sim-endian
This improves the logic a bit by making the host<->target translations
a bit more clear. The structs still bleed way too much between the two
worlds, but let's fix one thing at a time.
Mike Frysinger [Thu, 1 Jul 2021 00:30:43 +0000 (20:30 -0400)]
sim: m32r: fix virtual environment with Linux targets
We don't want to handle Linux syscalls when in the virtual environment,
just the user environment, so adjust the Linux traps logic to check for
that specifically (instead of just skipping the operating environment).
Also tweak some testcases to explicitly specify the environment they run
under rather than relying on the default matching their needs. This gets
the tests passing for all m32r targets.
Mike Frysinger [Wed, 30 Jun 2021 22:39:17 +0000 (18:39 -0400)]
sim: m32r: namespace Linux syscall table
The use of __NR_ defines in here conflicts a lot with the standard
host syscalls, sometimes leading to build errors (when the numbers
happen to be the same we get duplicate case handlers), and other
times leading to misbehavior (where the m32r syscall # is not what
is actually checked).
Namespace these using the standard that we already use: change the
__NR_ to TARGET_LINUX_SYS_ with a simple `sed`.
Also add a few missing includes so the code at least compiles.
Mike Frysinger [Tue, 29 Jun 2021 01:26:48 +0000 (21:26 -0400)]
cgen: split GUILE setting out
This makes it easier to override to point to an older version of guile.
The current cgen code doesn't work with guile-2, so need to point to an
older guile-1.8.
Mike Frysinger [Sun, 27 Jun 2021 06:14:29 +0000 (02:14 -0400)]
opcodes: cleanup nds32 variables
For the variables that don't need to be exported, mark them static.
For the ones shared between modules, add a "nds32_" prefix to avoid
collisions with these common variable names.
Mike Frysinger [Sun, 27 Jun 2021 05:55:50 +0000 (01:55 -0400)]
opcodes: constify & scope microblaze opcodes
This is exporting the variable "opcodes" as a large writable blob.
This is not a namespace friendly name, so add a "microblaze" prefix,
and then sprinkle const over its definition & use.
Pedro Alves [Fri, 11 Jun 2021 16:56:32 +0000 (17:56 +0100)]
Linux: Access memory even if threads are running
Currently, on GNU/Linux, if you try to access memory and you have a
running thread selected, GDB fails the memory accesses, like:
(gdb) c&
Continuing.
(gdb) p global_var
Cannot access memory at address 0x555555558010
Or:
(gdb) b main
Breakpoint 2 at 0x55555555524d: file access-mem-running.c, line 59.
Warning:
Cannot insert breakpoint 2.
Cannot access memory at address 0x55555555524d
This patch removes this limitation. It teaches the native Linux
target to read/write memory even if the target is running. And it
does this without temporarily stopping threads. We now get:
(gdb) c&
Continuing.
(gdb) p global_var
$1 = 123
(gdb) b main
Breakpoint 2 at 0x555555555259: file access-mem-running.c, line 62.
(The scenarios above work correctly with current GDBserver, because
GDBserver temporarily stops all threads in the process whenever GDB
wants to access memory (see prepare_to_access_memory /
done_accessing_memory). Freezing the whole process makes sense when
we need to be sure that we have a consistent view of memory and don't
race with the inferior changing it at the same time as GDB is
accessing it. But I think that's a too-heavy hammer for the default
behavior. I think that ideally, whether to stop all threads or not
should be policy decided by gdb core, probably best implemented by
exposing something like gdbserver's prepare_to_access_memory /
done_accessing_memory to gdb core.)
Currently, if we're accessing (reading/writing) just a few bytes, then
the Linux native backend does not try accessing memory via
/proc/<pid>/mem and goes straight to ptrace
PTRACE_PEEKTEXT/PTRACE_POKETEXT. However, ptrace always fails when
the ptracee is running. So the first step is to prefer
/proc/<pid>/mem even for small accesses. Without further changes
however, that may cause a performance regression, due to constantly
opening and closing /proc/<pid>/mem for each memory access. So the
next step is to keep the /proc/<pid>/mem file open across memory
accesses. If we have this, then it doesn't make sense anymore to even
have the ptrace fallback, so the patch disables it.
I've made it such that GDB only ever has one /proc/<pid>/mem file open
at any time. As long as a memory access hits the same inferior
process as the previous access, then we reuse the previously open
file. If however, we access memory of a different process, then we
close the previous file and open a new one for the new process.
If we wanted, we could keep one /proc/<pid>/mem file open per
inferior, and never close them (unless the inferior exits or execs).
However, having seen bfd patches recently about hitting too many open
file descriptors, I kept the logic to have only one file open tops.
Also, we need to handle memory accesses for processes for which we
don't have an inferior object, for when we need to detach a
fork-child, and we'd probaly want to handle caching the open file for
that scenario (no inferior for process) too, which would probably end
up meaning caching for last non-inferior process, which is very much
what I'm proposing anyhow. So always having one file open likely ends
up a smaller patch.
The next step is handling the case of GDB reading/writing memory
through a thread that is running and exits. The access should not
result in a user-visible failure if the inferior/process is still
alive.
Once we manage to open a /proc/<lwpid>/mem file, then that file is
usable for memory accesses even if the corresponding lwp exits and is
reaped. I double checked that trying to open the same
/proc/<lwpid>/mem path again fails because the lwp is really gone so
there's no /proc/<lwpid>/ entry on the filesystem anymore, but the
previously open file remains usable. It's only when the whole process
execs that we need to reopen a new file.
When the kernel destroys the whole address space, i.e., when the
process exits or execs, the reads/writes fail with 0 aka EOF, in which
case there's nothing else to do than returning a memory access
failure. Note this means that when we get an exec event, we need to
reopen the file, to access the process's new address space.
If we need to open (or reopen) the /proc/<pid>/mem file, and the LWP
we're opening it for exits before we open it and before we reap the
LWP (i.e., the LWP is zombie), the open fails with EACCES. The patch
handles this by just looking for another thread until it finds one
that we can open a /proc/<pid>/mem successfully for.
If we need to open (or reopen) the /proc/<pid>/mem file, and the LWP
we're opening has exited and we already reaped it, which is the case
if the selected thread is in THREAD_EXIT state, the open fails with
ENOENT. The patch handles this the same way as a zombie race
(EACCES), instead of checking upfront whether we're accessing a
known-exited thread, because that would result in more complicated
code, because we also need to handle accessing lwps that are not
listed in the core thread list, and it's the core thread list that
records the THREAD_EXIT state.
The patch includes two testcases:
#1 - gdb.base/access-mem-running.exp
This is the conceptually simplest - it is single-threaded, and has
GDB read and write memory while the program is running. It also
tests setting a breakpoint while the program is running, and checks
that the breakpoint is hit immediately.
This one is more elaborate, as it continuously spawns short-lived
threads in order to exercise accessing memory just while threads are
exiting. It also spawns two different processes and alternates
accessing memory between the two processes to exercise the reopening
the /proc file frequently. This also ends up exercising GDB reading
from an exited thread frequently. I confirmed by putting abort()
calls in the EACCES/ENOENT paths added by the patch that we do hit
all of them frequently with the testcase. It also exits the
process's main thread (i.e., the main thread becomes zombie), to
make sure accessing memory in such a corner-case scenario works now
and in the future.
The tests fail on GNU/Linux native before the code changes, and pass
after. They pass against current GDBserver, again because GDBserver
supports memory access even if all threads are running, by
transparently pausing the whole process.
gdb/ChangeLog:
yyyy-mm-dd Pedro Alves <pedro@palves.net>
PR mi/15729
PR gdb/13463
* linux-nat.c (linux_nat_target::detach): Close the
/proc/<pid>/mem file if it was open for this process.
(linux_handle_extended_wait) <PTRACE_EVENT_EXEC>: Close the
/proc/<pid>/mem file if it was open for this process.
(linux_nat_target::mourn_inferior): Close the /proc/<pid>/mem file
if it was open for this process.
(linux_nat_target::xfer_partial): Adjust. Do not fall back to
inf_ptrace_target::xfer_partial for memory accesses.
(last_proc_mem_file): New.
(maybe_close_proc_mem_file): New.
(linux_proc_xfer_memory_partial_pid): New, with bits factored out
from linux_proc_xfer_partial.
(linux_proc_xfer_partial): Delete.
(linux_proc_xfer_memory_partial): New.
gdb/testsuite/ChangeLog
yyyy-mm-dd Pedro Alves <pedro@palves.net>
Andrei Homescu [Thu, 1 Jul 2021 11:01:55 +0000 (12:01 +0100)]
readelf: Reset file position to beginning for thin archive members
* readelf.c (process_archive): Reset file position to the
beginning when calling process_object for thin archive members.
* testsuite/binutils-all/readelf.exp: Add test.
* testsuite/binutils-all/readelf.h.thin: New file.
arm: don't treat XScale features as part of the FPU [PR 28031]
Although the XScale and its iwMMX extensions are implemented in the
Arm co-processor space, they are not considered to be part of the FPU
specification. In particular, they cannot be enabled or disabled via
a .fpu directive. It's therefore incorrect to strip these properties
when a new .fpu directive is encountered.
Note that the legacy Maverick co-processor is considered to be a FPU
and it is possible to control this via the .fpu directive.
Mike Frysinger [Wed, 30 Jun 2021 02:06:30 +0000 (22:06 -0400)]
sim: ppc: unify (most) compiler warnings with common code
Copy most of the common build warning logic over from the common
code to help keep code behavior a bit consistent, and turn them
on by default. We disable a few flags for now until we can clean
the code up.
Mike Frysinger [Wed, 30 Jun 2021 17:01:17 +0000 (13:01 -0400)]
sim: cris/frv/iq2000/lm32: merge with common configure script
Now that the scache logic has been migrated into the common code,
there's nothing specific in these configure scripts, so merge them
into the common one.
The frv unique logic can be moved to a dedicated include and merged
in the common configure since the flag has been scoped to the arch.
Mike Frysinger [Tue, 29 Jun 2021 02:39:16 +0000 (22:39 -0400)]
sim: unify scache settings
The cgen scache module is enabled by every cgen port, and with the
same default value of 16k (which matches the common default value).
Let's pull this option out of the individual ports (via CPPFLAGS)
and into the common code (via config.h).
The object itself is compiled only for cgen ports atm, so that part
doesn't change. The scache code is initialized dynamically via the
modules.c logic. That's why the profile code needs an additional
CGEN_ARCH check.
This will allow us to collapse arch configure files more. Merging
the source files will require more future work, but integrating the
cgen & non-cgen worlds itself will take a lot.
Mike Frysinger [Tue, 29 Jun 2021 02:10:28 +0000 (22:10 -0400)]
sim: delete unused model settings
These were never fully migrated from the psim to common code, and since
we've finished moving the logic into the runtime sim state, we won't ever
need these. So punt them.
Mike Frysinger [Tue, 29 Jun 2021 02:07:44 +0000 (22:07 -0400)]
sim: move default model to the runtime sim state
This kills off another compile-time option by moving the setting to
the individual arch runtimes. This will allow dynamic selection by
the arch when doing a single build with multiple arches.
The sim_model_init rework is a little funky. In the past it was
disabled entirely if no default model was set. We maintain the
spirit of the logic by gating the fallback logic on whether the
port has defined any models.
Mike Frysinger [Tue, 29 Jun 2021 01:42:56 +0000 (21:42 -0400)]
sim: namespace sim_machs
We want to do a single build with all arches in one binary which means
we need to namespace sim_machs on a per-arch basis. Move it from a
global variable to the sim description structure so it can be setup at
runtime.
Changing the SIM_MODEL->num from an enum to an int is unfortunate, but
we specifically don't want to maintain a centralized list anymore, and
this was never used directly in common code, just passed to per-arch
callbacks.
Mike Frysinger [Wed, 30 Jun 2021 00:44:55 +0000 (20:44 -0400)]
sim: fix arch Makefile regen when unified
The $(arch) variable is only setup for cgen ports, so calculate this
value dynamically. We also need to generate multiple inputs in order
to properly recreate the subdir Makefile, so list them all.
Mike Frysinger [Wed, 30 Jun 2021 00:33:14 +0000 (20:33 -0400)]
sim: use -Wno-error=maybe-uninitialized
We have some code tripping this warning, but it depends on the gcc
version & optimization levels. We've added some hints to the code
so some versions of gcc work better, but still not all. Let's just
disable the warning like gdb does.
Simon Marchi [Tue, 29 Jun 2021 16:05:14 +0000 (12:05 -0400)]
gdb: introduce FRAME_SCOPED_DEBUG_ENTER_EXIT
Introduce FRAME_SCOPED_DEBUG_ENTER_EXIT and use it to print enter/exit
messages in important frame-related functions. I think this helps
understand which lower-level operations are done as part of which
higher-level operation. And it helps visually skip over a higher-level
operation you are not interested in.
Here's an example, combined with some py-unwind messages:
Simon Marchi [Tue, 29 Jun 2021 16:05:03 +0000 (12:05 -0400)]
gdb: add names to unwinders, add debug messages when looking for unwinder
I wrote this while debugging a problem where the expected unwinder for a
frame wasn't used. It adds messages to show which unwinders are
considered for a frame, why they are not selected (if an exception is
thrown), and finally which unwinder is selected in the end.
To be able to show a meaningful, human-readable name for the unwinders,
add a "name" field to struct frame_unwind, and update all instances to
include a name.
Here's an example of the output:
[frame] frame_unwind_find_by_frame: this_frame=0
[frame] frame_unwind_try_unwinder: trying unwinder "dummy"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2 tailcall"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "inline"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "jit"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "python"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "amd64 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "i386 epilogue"
[frame] frame_unwind_try_unwinder: no
[frame] frame_unwind_try_unwinder: trying unwinder "dwarf2"
[frame] frame_unwind_try_unwinder: yes
gdb/ChangeLog:
* frame-unwind.h (struct frame_unwind) <name>: New. Update
instances everywhere to include this field.
* frame-unwind.c (frame_unwind_try_unwinder,
frame_unwind_find_by_frame): Add debug messages.
Simon Marchi [Tue, 29 Jun 2021 16:03:50 +0000 (12:03 -0400)]
gdb: introduce frame_debug_printf
Introduce frame_debug_printf, to convert the "frame" debug messages to
the new system. Replace fprint_frame with a frame_info::to_string
method that returns a string, like what was done with
frame_id::to_string. This makes it easier to use with
frame_debug_printf.
gdb/ChangeLog:
* frame.h (frame_debug_printf): New.
* frame.c: Use frame_debug_printf throughout when printing frame
debug messages.
* amd64-windows-tdep.c: Likewise.
* value.c: Likewise.
/* Search function to lookup a (non-exited) thread by 'ptid'. Only
searches in threads of INF. */
extern struct thread_info *find_thread_ptid (inferior *inf, ptid_t ptid);
Retain the former, remove the latter. Tested by rebuilding.
gdb/ChangeLog:
2021-06-29 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdbthread.h (find_thread_ptid): Remove the duplicate declaration.
Mike Frysinger [Mon, 28 Jun 2021 03:21:26 +0000 (23:21 -0400)]
sim: callback: add printf attributes
This helps these funcs get printf format checking coverage.
The sim-io.c hack as a result is a bit unfortunate, but the compiler
throws warnings when printing with empty strings. In this one case,
we actually want that due to the side-effect of the callback halting
execution for us.
Mike Frysinger [Mon, 28 Jun 2021 03:19:06 +0000 (23:19 -0400)]
sim: callback: drop unused printf helpers
These cover functions aren't used anywhere, so drop them. There was
one caller, but it's old DOS code that most likely hasn't been tested
in years, so just delete that too.
projects / thirdparty / binutils-gdb.git / log
