Gary Benson [Fri, 15 May 2020 14:03:42 +0000 (15:03 +0100)]
Fix "control reaches end of non-void function" errors in testsuite
When running the testsuite with clang, a number of testcases fail to
build with the following errors:
warning: control reaches end of non-void function [-Wreturn-type]
warning: control may reach end of non-void function [-Wreturn-type]
This prevents a number of testcases from executing. This commit fixes.
Tom de Vries [Fri, 15 May 2020 12:49:48 +0000 (14:49 +0200)]
[gdb/testsuite] Rename *.exp.in to *.exp.tcl
Say we have some common tcl code that we want to include in test-cases
t1.exp and t1.exp.
We could put the common code into a file common.exp alongside the test-cases,
but that will make dejagnu treat that file as another test-case. To prevent
this, we use a suffix, currently .in, in other words we put the common code in
a file common.exp.in.
The .in suffix however is also used in autoconf, which might cause confusion.
This commit is for the benefit of GDB, but as the binutils-gdb
repository shares the contrib/ directory with gcc, this commit must
first be applied to gcc then copied back to binutils-gdb.
This commit extends the two scripts contrib/dg-extract-results.{py,sh}
to handle some new, GDB specific test result types. These test
results types should never appear in GCC, or any other tool that
shares the contrib/ directly, so this change should be harmless.
In this patch series:
https://sourceware.org/pipermail/gdb-patches/2020-April/167847.html
changes were made in GDB's use of Dejagnu so that two additional
conditions could be detected, these are:
1. Test names that contain either the build or source paths. Such
test names make it difficult to compare the results of two test runs
of GDB from two different directories, and
2. Duplicate test names. Duplicates make it difficult to track down
exactly which test has failed.
When running Dejagnu on GDB we can now (sometimes) see two additional
test result types matching the above conditions, these are '# of paths
in test names' and '# of duplicate test names'.
If the test is run in parallel mode (make -j...) then these extra test
results will appear in the individual test summary files, but are not
merged into the final summary file.
Additionally, within the summary file there are now two new types of
test summary line, these are 'PATH: ...' and 'DUPLICATE: ...', these
allow users to quickly search the test summary to track down where the
offending test names are. These lines are similarly not merged into
the unified gdb.sum file after a parallel test run.
This commit extends the dg-extract-results.* scripts to calculate the
totals for the two new result types, and to copy the new test summary
lines into the unified summary file.
contrib/ChangeLog:
* dg-extract-results.py: Update from gcc repo.
* dg-extract-results.sh: Likewise.
Pedro Alves [Fri, 15 May 2020 10:22:47 +0000 (11:22 +0100)]
Fix gdb.multi/multi-kill.exp
The previous patch misssed declaring the 'testpid' array as namespace
variable. While it at, might as well go back to having start_inferior
refer to the "global" testpid, using "variable" too.
gdb/testsuite/ChangeLog:
2020-05-15 Pedro Alves <palves@redhat.com>
* gdb.multi/multi-kill.exp (start_inferior): Remove
'testpid' parameter. Refer to namespace variable directly.
(testpid): Declare as namespace variable.
Pedro Alves [Fri, 15 May 2020 10:09:51 +0000 (11:09 +0100)]
Fix global variable collision in gdb.multi/multi-kill.exp
The new gdb.multi/multi-kill.exp testcase added an 'testpid' array,
which may conflict with other global 'testpid' variables used by other
testcases, resulting in:
...
ERROR: tcl error sourcing
/data/gdb_versions/devel/src/gdb/testsuite/gdb.multi/multi-kill.exp.
ERROR: can't set "testpid(1)": variable isn't array
while executing
"set testpid($num) [get_integer_valueof "pid" -1]"
or
$ runtest gdb.threads/check-libthread-db.exp gdb.multi/multi-kill.exp
...
Running /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.multi/multi-kill.exp ...
Running /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/check-libthread-db.exp ...
ERROR: tcl error sourcing /home/pedro/gdb/binutils-gdb/src/gdb/testsuite/gdb.threads/check-libthread-db.exp.
ERROR: can't set "testpid": variable is array
while executing
"set testpid [spawn_id_get_pid $test_spawn_id]"
("uplevel" body line 8)
Fix this with a namespace, like gdb.linespec/explicit.exp does.
gdb/testsuite/ChangeLog:
2020-05-15 Pedro Alves <palves@redhat.com>
* gdb.multi/multi-kill.exp: Wrap in namespace.
(start_inferior): Add TESTPID parameter. Use it instead of the
testpid global.
(top level): Define empty TESTPID array, and pass it down to
start_inferior.
Hannes Domani [Mon, 11 May 2020 17:18:31 +0000 (19:18 +0200)]
Enable hardware breakpoints for gdbserver on Windows
When trying to use hardware breakpoints with gdbserver you get this error:
(gdb) hbreak main
Hardware assisted breakpoint 2 at 0x40162d: file gdb-9493.c, line 5.
(gdb) c
Continuing.
Warning:
Cannot insert hardware breakpoint 2.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
It turns out the respective types just needed to be added to the
appropriate callback functions, because x86_dr_(insert|remove)_watchpoint
already handles them.
Alan Modra [Fri, 15 May 2020 08:36:05 +0000 (18:06 +0930)]
Fix tight loop on recursively-defined symbols
This patch fixes a bug in GAS where the assembler enters a tight loop
when attempting to resolve recursively-defined symbols, e.g. when
trying to assemble "a=a".
This is a regression introduced between binutils 2.32 and 2.33,
by commit 1903f1385bff9
* symbols.c (struct local_symbol): Update comment.
(resolve_symbol_value): For resolved symbols equated to other
symbols, verify that the referenced symbol is not a local_symbol
before accessing sy_value. Don't leave symbol loops during
finalize_syms resolution.
* testsuite/gas/all/assign-bad-recursive.d: New test.
* testsuite/gas/all/assign-bad-recursive.l: Error output for test.
* testsuite/gas/all/assign-bad-recursive.s: Assembly for test.
* testsuite/gas/all/gas.exp: Run it.
While it is the case that AMD processors have an LBR (last branch
record) bit in the DebugCtl MSR, it seems that it affects only four
MSRs when enabled. The names of these MSRs are LastBranchToIP,
LastBranchFromIP, LastIntToIP, and LastIntFromIP. I can find no
mention of anything more extensive. While looking at an Intel
architecture document, I noticed that Intel's P6 family from the
mid-90s had registers of the same name.
Therefore...
This commit disables "record btrace bts" support in GDB for AMD
processors.
Using the test case from gdb.base/break.exp, the sessions
below show the expected behavior (run on a machine with an
Intel processor) versus that on a machine with an AMD processor.
The AMD processor in question is reported as follows by "lscpu":
AMD Ryzen Threadripper 2950X 16-Core Processor . Finally, I'll
note that the AMD machine is actually a VM, but I see similar
behavior on both the virtualization host and the VM.
Intel machine - Desired behavior:
[kevinb@mohave gdb]$ ./gdb -q testsuite/outputs/gdb.base/break/break
Reading symbols from testsuite/outputs/gdb.base/break/break...
(gdb) start
Temporary breakpoint 1 at 0x401179: file /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c, line 43.
Starting program: /home/kevinb/sourceware-git/native-build/bld/gdb/testsuite/outputs/gdb.base/break/break
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd748, envp=0x7fffffffd758)
at /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c:43
43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */
(gdb) record btrace
(gdb) b factorial
Breakpoint 2 at 0x40121b: file /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c, line 63.
(gdb) c
Continuing.
Breakpoint 2, factorial (value=6)
at /home/kevinb/sourceware-git/native-build/bld/../../binutils-gdb/gdb/testsuite/gdb.base/break.c:63
63 if (value > 1) { /* set breakpoint 7 here */
(gdb) info record
Active record target: record-btrace
Recording format: Branch Trace Store.
Buffer size: 64kB.
Recorded 768 instructions in 22 functions (0 gaps) for thread 1 (process 19215).
(gdb) record function-call-history
13 do_lookup_x
14 _dl_lookup_symbol_x
15 _dl_fixup
16 _dl_runtime_resolve_xsavec
17 atoi
18 strtoq
19 ____strtoll_l_internal
20 atoi
21 main
22 factorial
(gdb) record instruction-history
759 0x00007ffff7ce0917 <____strtoll_l_internal+647>: pop %r15
760 0x00007ffff7ce0919 <____strtoll_l_internal+649>: retq
761 0x00007ffff7cdd064 <atoi+20>: add $0x8,%rsp
762 0x00007ffff7cdd068 <atoi+24>: retq
763 0x00000000004011b1 <main+75>: mov %eax,%edi
764 0x00000000004011b3 <main+77>: callq 0x401210 <factorial>
765 0x0000000000401210 <factorial+0>: push %rbp
766 0x0000000000401211 <factorial+1>: mov %rsp,%rbp
767 0x0000000000401214 <factorial+4>: sub $0x10,%rsp
768 0x0000000000401218 <factorial+8>: mov %edi,-0x4(%rbp)
AMD machine - Wrong behavior:
[kev@f32-1 gdb]$ ./gdb -q testsuite/outputs/gdb.base/break/break
Reading symbols from testsuite/outputs/gdb.base/break/break...
(gdb) start
Temporary breakpoint 1 at 0x401179: file /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c, line 43.
Starting program: /mesquite2/sourceware-git/f32-master/bld/gdb/testsuite/outputs/gdb.base/break/break
Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd5b8, envp=0x7fffffffd5c8)
at /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c:43
43 if (argc == 12345) { /* an unlikely value < 2^16, in case uninited */ /* set breakpoint 6 here */
(gdb) record btrace
(gdb) b factorial
Breakpoint 2 at 0x40121b: file /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c, line 63.
(gdb) c
Continuing.
Breakpoint 2, factorial (value=6)
at /ironwood1/sourceware-git/f32-master/bld/../../worktree-master/gdb/testsuite/gdb.base/break.c:63
63 if (value > 1) { /* set breakpoint 7 here */
(gdb) info record
Active record target: record-btrace
Recording format: Branch Trace Store.
Buffer size: 64kB.
warning: Recorded trace may be incomplete at instruction 7737 (pc = 0x405000).
warning: Recorded trace may be incomplete at instruction 7739 (pc = 0x0).
Recorded 7740 instructions in 46 functions (2 gaps) for thread 1 (process 1402911).
(gdb) record function-call-history
37 ??
38 values
39 some_enum_global
40 ??
41 some_union_global
42 some_variable
43 ??
44 [decode error (2): unknown instruction]
45 ??
46 [decode error (2): unknown instruction]
(gdb) record instruction-history
7730 0x0000000000404ff3: add %al,(%rax)
7731 0x0000000000404ff5: add %al,(%rax)
7732 0x0000000000404ff7: add %al,(%rax)
7733 0x0000000000404ff9: add %al,(%rax)
7734 0x0000000000404ffb: add %al,(%rax)
7735 0x0000000000404ffd: add %al,(%rax)
7736 0x0000000000404fff: .byte 0x0
7737 0x0000000000405000: Cannot access memory at address 0x405000
Lastly, I'll note that I see a lot of gdb.btrace failures without
this commit. Worse still, the results aren't always the same which
causes a lot of noise when comparing test results.
gdb: infrun: consume multiple events at each pass in stop_all_threads
[Simon: I send this patch on behalf of Laurent Morichetti, I added the
commit message and performance measurement stuff.
Also, this patch is better viewed with "git show -w".]
stop_all_threads, in infrun.c, is used to stop all running threads on
targets that are always non-stop. It's used, for example, when the
program hits a breakpoint while GDB is set to "non-stop off". It sends
a stop request for each running thread, then collects one wait event for
each.
Since new threads can spawn while we are stopping the threads, it's
written in a way where it makes multiple such "send stop requests to
running threads & collect wait events" passes. The function completes
when it has made two passes where it hasn't seen any running threads.
With the way it's written right now is, it iterates on the thread list,
sending a stop request for each running thread. It then waits for a
single event, after which it iterates through the thread list again. It
sends stop requests for any running threads that's been created since
the last iteration. It then consumes another single wait event.
This makes it so we iterate on O(n^2) threads in total, where n is the
number of threads. This patch changes the function to reduce it to
O(n). This starts to have an impact when dealing with multiple
thousands of threads (see numbers below). At each pass, we know the
number of outstanding stop requests we have sent, for which we need to
collect a stop event. We can therefore loop to collect this many stop
events before proceeding to the next pass and iterate on the thread list
again.
To check the performance improvements with this patch, I made an
x86/Linux program with a large number of idle threads (varying from 1000
to 10000). The program's main thread hits a breakpoint once all these
threads have started, which causes stop_all_threads to be called to stop
all these threads. I measured (by patching stop_all_threads):
- the execution time of stop_all_threads
- the total number of threads we iterate on during the complete
execution of the function (the total number of times we execute the
"for (thread_info *t : all_non_exited_threads ())" loop)
Nikita Ermakov [Thu, 14 May 2020 22:57:57 +0000 (08:27 +0930)]
gold: powerpc: Test whether sym is not a plugin in do_gc_mark_symbol
sym->object() could be either a Plugin or Powerpc_relobj. There could
be a situation when Pluginobj would be proccessed in
ppc_object->get_opd_ent(dst_off) as Powerpc_relobj and it leads to the
segmentation fault.
* powerpc.cc (do_gc_mark_symbol): Don't segfault on plugin symbols.
Simon Marchi [Thu, 14 May 2020 17:46:38 +0000 (13:46 -0400)]
gdb: remove TYPE_CODE macro
Remove TYPE_CODE, changing all the call sites to use type::code
directly. This is quite a big diff, but this was mostly done using sed
and coccinelle. A few call sites were done by hand.
gdb/ChangeLog:
* gdbtypes.h (TYPE_CODE): Remove. Change all call sites to use
type::code instead.
Simon Marchi [Thu, 14 May 2020 17:45:40 +0000 (13:45 -0400)]
gdb: add type::code / type::set_code
Add the code and set_code methods on code, in order to remove the
TYPE_CODE macro. In this patch, the TYPE_CODE macro is changed to use
type::code, so all the call sites that are used to set the type code are
changed to use type::set_code. The next patch will remove TYPE_CODE
completely.
gdb/ChangeLog:
* gdbtypes.h (struct type) <code, set_code>: New methods.
(TYPE_CODE): Use type::code. Change all call sites used to set
the code to use type::set_code instead.
Tom de Vries [Thu, 14 May 2020 15:24:49 +0000 (17:24 +0200)]
[gdb/testsuite] Split up multi-exec test-cases
With test-case gdb.base/align.exp and target board native-gdbserver, we run
into:
...
(gdb) file outputs/gdb.base/align/c/align^M
Reading symbols from outputs/gdb.base/align/c/align...^M
(gdb) delete breakpoints^M
(gdb) info breakpoints^M
No breakpoints or watchpoints.^M
(gdb) break main^M
Breakpoint 1 at 0x4004ab: file outputs/gdb.base/align/c/align.c, line 838.^M
(gdb) kill^M
The program is not being run.^M
(gdb) spawn gdbserver --once localhost:2592 outputs/gdb.base/align/align^M
Process outputs/gdb.base/align/align created; pid = 6946^M
Listening on port 2592^M
target remote localhost:2592^M
Remote debugging using localhost:2592^M
warning: Mismatch between current exec-file outputs/gdb.base/align/c/align^M
and automatically determined exec-file outputs/gdb.base/align/align^M
exec-file-mismatch handling is currently "ask"^M
Load new symbol table from "outputs/gdb.base/align/align"? (y or n) Quit^M
(gdb) ERROR: test suppressed
...
Fix this by turning this and similar test-cases into regular, single
executable test-cases.
This fixes 100+ FAILs with target board native-gdbserver.
gdb/infrun: handle already-exited threads when attempting to stop
In stop_all_threads, GDB sends signals to other threads in an attempt
to stop them. While in a typical scenario the expected wait status is
TARGET_WAITKIND_STOPPED, it is possible that the thread GDB attempted
to stop has already terminated. If so, a waitstatus other than
TARGET_WAITKIND_STOPPED would be received. Handle this case
appropriately.
If a wait status that denotes thread termination is ignored, GDB goes
into an infinite loop in stop_all_threads.
E.g.:
$ gdb ./a.out
(gdb) start
...
(gdb) add-inferior -exec ./a.out
...
(gdb) inferior 2
...
(gdb) start
...
(gdb) set schedule-multiple on
(gdb) set debug infrun 2
(gdb) continue
Continuing.
infrun: clear_proceed_status_thread (process 10449)
infrun: clear_proceed_status_thread (process 10453)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 10449
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10449] at 0x55555555514e
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: proceed: resuming process 10453
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 10453] at 0x55555555514e
infrun: prepare_to_wait
infrun: Found 2 inferiors, starting at #0
infrun: target_wait (-1.0.0, status) =
infrun: 10449.10449.0 [process 10449],
infrun: status->kind = exited, status = 0
infrun: handle_inferior_event status->kind = exited, status = 0
[Inferior 1 (process 10449) exited normally]
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun: process 10453 executing, need stop
infrun: target_wait (-1.0.0, status) =
infrun: 10453.10453.0 [process 10453],
infrun: status->kind = exited, status = 0
infrun: stop_all_threads status->kind = exited, status = 0 process 10453
infrun: process 10453 executing, already stopping
infrun: target_wait (-1.0.0, status) =
infrun: -1.0.0 [process -1],
infrun: status->kind = no-resumed
infrun: infrun_async(0)
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
infrun: stop_all_threads status->kind = no-resumed process -1
infrun: process 10453 executing, already stopping
...
And this polling goes on forever. This patch prevents the infinite
looping behavior. For the same scenario above, we obtain the
following behavior:
...
(gdb) continue
Continuing.
infrun: clear_proceed_status_thread (process 31229)
infrun: clear_proceed_status_thread (process 31233)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 31229
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31229] at 0x55555555514e
infrun: infrun_async(1)
infrun: prepare_to_wait
infrun: proceed: resuming process 31233
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [process 31233] at 0x55555555514e
infrun: prepare_to_wait
infrun: Found 2 inferiors, starting at #0
infrun: target_wait (-1.0.0, status) =
infrun: 31229.31229.0 [process 31229],
infrun: status->kind = exited, status = 0
infrun: handle_inferior_event status->kind = exited, status = 0
[Inferior 1 (process 31229) exited normally]
infrun: stop_waiting
infrun: stop_all_threads
infrun: stop_all_threads, pass=0, iterations=0
infrun: process 31233 executing, need stop
infrun: target_wait (-1.0.0, status) =
infrun: 31233.31233.0 [process 31233],
infrun: status->kind = exited, status = 0
infrun: stop_all_threads status->kind = exited, status = 0 process 31233
infrun: saving status status->kind = exited, status = 0 for 31233.31233.0
infrun: process 31233 not executing
infrun: stop_all_threads, pass=1, iterations=1
infrun: process 31233 not executing
infrun: stop_all_threads done
(gdb)
The exit event from Inferior 1 is received and shown to the user.
The exit event from Inferior 2 is not displayed, but kept pending.
(gdb) info inferiors
Num Description Connection Executable
* 1 <null> a.out
2 process 31233 1 (native) a.out
(gdb) inferior 2
[Switching to inferior 2 [process 31233] (a.out)]
[Switching to thread 2.1 (process 31233)]
Couldn't get registers: No such process.
(gdb) continue
Continuing.
infrun: clear_proceed_status_thread (process 31233)
infrun: clear_proceed_status_thread: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0).
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming process 31233
infrun: resume: thread process 31233 has pending wait status status->kind = exited, status = 0 (currently_stepping=0).
infrun: prepare_to_wait
infrun: Using pending wait status status->kind = exited, status = 0 for process 31233.
infrun: target_wait (-1.0.0, status) =
infrun: 31233.31233.0 [process 31233],
infrun: status->kind = exited, status = 0
infrun: handle_inferior_event status->kind = exited, status = 0
[Inferior 2 (process 31233) exited normally]
infrun: stop_waiting
(gdb) info inferiors
Num Description Connection Executable
1 <null> a.out
* 2 <null> a.out
(gdb)
When a process exits and we leave the process exit event pending, we
need to make sure that at least one thread is left listed in the
inferior's thread list. This is necessary in order to make sure we
have a thread that we can later resume, so the process exit event can
be collected/reported.
When native debugging, the GNU/Linux back end already makes sure that
the last LWP isn't deleted.
When remote debugging against GNU/Linux GDBserver, the GNU/Linux
GDBserver backend also makes sure that the last thread isn't deleted
until the process exit event is reported to GDBserver core.
However, between the backend reporting the process exit event to
GDBserver core, and GDB consuming the event, GDB may update the thread
list and find no thread left in the process. The process exit event
will be pending somewhere in GDBserver's stop reply queue, or
gdb/remote.c's queue, or whathever other event queue inbetween
GDBserver and infrun.c's handle_inferior_event.
This patch tweaks remote.c's target_update_thread_list implementation
to avoid deleting the last thread of an inferior.
In the past, this case of inferior-with-no-threads led to a special
case at the bottom of handle_no_resumed, where it reads:
/* Note however that we may find no resumed thread because the whole
process exited meanwhile (thus updating the thread list results
in an empty thread list). In this case we know we'll be getting
a process exit event shortly. */
for (inferior *inf : all_non_exited_inferiors (ecs->target))
In current master, that code path is still reachable with the
gdb.threads/continue-pending-after-query.exp testcase, when tested
against GDBserver, with "maint set target-non-stop" forced "on".
With this patch, the scenario that loop was concerned about is still
properly handled, because the loop above it finds the process's last
thread with "executing" set to true, and thus the handle_no_resumed
function still returns true.
Since GNU/Linux native and remote are the only targets that support
non-stop mode, and with this patch, we always make sure the inferior
has at least one thread, this patch also removes that "inferior with
no threads" special case handling from handle_no_resumed.
Since remote.c now has a special case where we treat a thread that has
already exited as if it was still alive, we might need to tweak
remote.c's target_thread_alive implementation to return true for that
thread without querying the remote side (which would say "no, not
alive"). After inspecting all the target_thread_alive calls in the
codebase, it seems that only the one from prune_threads could result
in that thread being accidentally deleted. There's only one call to
prune_threads in GDB's common code, so this patch handles this by
replacing the prune_threads call with a delete_exited_threads call.
This seems like an improvement anyway, because we'll still be doing
what the comment suggests we want to do, and, we avoid remote protocol
traffic.
Regression-tested on X86_64 Linux.
gdb/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Tom de Vries <tdevries@suse.de>
Pedro Alves <palves@redhat.com>
PR threads/25478
* infrun.c (stop_all_threads): Do NOT ignore
TARGET_WAITKIND_NO_RESUMED, TARGET_WAITKIND_THREAD_EXITED,
TARGET_WAITKIND_EXITED, TARGET_WAITKIND_SIGNALLED wait statuses
received.
(handle_no_resumed): Remove code handling a live inferior with no
threads.
* remote.c (has_single_non_exited_thread): New.
(remote_target::update_thread_list): Do not delete a thread if is
the last thread of the process.
* thread.c (thread_select): Call delete_exited_threads instead of
prune_threads.
gdb/testsuite/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
Pedro Alves <palves@redhat.com>
* gdb.multi/multi-exit.c: New file.
* gdb.multi/multi-exit.exp: New file.
* gdb.multi/multi-kill.c: New file.
* gdb.multi/multi-kill.exp: New file.
gdb/infrun: enable/disable thread events of all targets in stop_all_threads
In stop_all_threads, the thread events of the current top target are
enabled at the beginning of the function and then disabled at the end
(at scope exit time). Because there may be multiple targets whose
thread lists will be updated and whose threads are stopped,
enable/disable thread events for all targets.
This update caused a change in the annotations. In particular, a
"frames-invalid" annotation is printed one more time due to switching
the current inferior. Hence, gdb.base/annota1.exp and
gdb.cp/annota2.exp tests are also updated.
Regression-tested on X86_64 Linux using the default board file and the
native-extended-gdbserver board file.
gdb/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (stop_all_threads): Enable/disable thread events of all
targets. Move a debug message denoting the end of the function
into the SCOPED_EXIT block.
gdb/testsuite/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* gdb.base/annota1.exp: Update the expected output.
* gdb.cp/annota2.exp: Ditto.
gdb: introduce 'all_non_exited_process_targets' and 'switch_to_target_no_thread'
Introduce two new convenience functions:
1. all_non_exited_process_targets: returns a collection of all process
stratum targets that have non-exited inferiors on them. Useful for
iterating targets.
2. switch_to_target_no_thread: switch the context to the first
inferior of the given target, and to no selected thread.
gdb/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* process-stratum-target.h: Include <set>.
(all_non_exited_process_targets, switch_to_target_no_thread): New
function declarations.
* process-stratum-target.c (all_non_exited_process_targets)
(switch_to_target_no_thread): New function implementations.
gdb/infrun: extract out a code piece into 'mark_non_executing_threads' function
This is a refactoring. The extracted function is placed deliberately
before 'stop_all_threads' because the function will be re-used there
in a subsequent patch for handling an exit status kind received from
a thread that GDB attempted to stop.
gdb/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (handle_inferior_event): Extract out a piece of code
into...
(mark_non_executing_threads): ...this new function.
gdb/infrun: move a 'regcache_read_pc' call down to first use
In infrun.c's resume_1 function, move the definition of the local
variable PC down to its first use. This is useful if the thread we want
to resume is already gone with a pending exit event, because we avoid
the error we would see otherwise when trying to read the PC.
gdb/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* infrun.c (resume_1): Move a 'regcache_read_pc' call down to first
use.
It possible that a thread whose PC we attempt to read is already dead.
In this case, 'regcache_read_pc' errors out. This impacts the
"proceed" execution flow, where GDB quits early before having a chance
to check if there exists a pending event. To remedy, keep going with
a 0 value for the PC if 'regcache_read_pc' fails. Because the value
of PC before resuming a thread is mostly used for storing and checking
the next time the thread stops, this tolerance is expected to be
harmless for a dead thread/process.
gdb/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* regcache.c (regcache_read_pc_protected): New function
implementation that returns 0 if the PC cannot read via
'regcache_read_pc'.
* infrun.c (proceed): Call 'regcache_read_pc_protected'
instead of 'regcache_read_pc'.
(keep_going_pass_signal): Ditto.
gdbsupport/ChangeLog:
2020-05-14 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* common-regcache.h (regcache_read_pc_protected): New function
declaration.
Nelson Chu [Wed, 13 May 2020 08:05:45 +0000 (16:05 +0800)]
RISC-V: Add elfNN_riscv_mkobject to initialize RISC-V tdata.
For now we only have one char pointer in RISC-V tdata, so it should be fine.
But once we need more elements in tdata, then we may get some uninitialize
or unexpected values. I do meet the same problem when extending the RISC-V
tdata.
bfd/
elfnn-riscv.c (elfNN_riscv_mkobject): New function. We need this
to initialize RISC-V tdata.
gdb: update the copyright year in async-event.[ch]
The async-event.[ch] files were introduced recently as a result of
splitting the event-loop. I believe the copyright year update was
just an oversight. So, this patch fixes that.
gdb/ChangeLog:
2020-05-13 Tankut Baris Aktemur <tankut.baris.aktemur@intel.com>
* async-event.c: Update the copyright year.
* async-event.h: Update the copyright year.
Tom de Vries [Tue, 12 May 2020 12:59:01 +0000 (14:59 +0200)]
[gdb/testsuite] Fix incorrect string concat in jit-elf.exp
When running test-case gdb.base/jit-elf.exp with target board
cc-with-gdb-index, we get:
...
spawn -ignore SIGHUP gdb/contrib/cc-with-tweaks.sh -i gcc \
-fno-stack-protector src/gdb/testsuite/gdb.base/jit-elf-main.c \
-fdiagnostics-color=never -DATTACH=1 -DLOAD_ADDRESS=0x7000000 \
-DLOAD_INCREMENT=0x1000000 -g -lm \
-o outputs/gdb.base/jit-elf/jit-elf-main"-attach"^M
outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \
No such file or directory.^M
output is:
outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \
No such file or directory.^M
gdb compile failed, outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \
No such file or directory.
UNTESTED: gdb.base/jit-elf.exp: failed to compile jit-elf-main"-attach"
...
The problem is a string concat in jit-elf.exp:
...
${main_binfile}"-attach"
...
which is intended to generate string 'jit-elf-main-attach' but instead
generates string 'jit-elf-main"-attach"'.
Fix this by using "${main_binfile}-attach" instead.
Tom de Vries [Tue, 12 May 2020 12:41:47 +0000 (14:41 +0200)]
[gdb/testsuite] Fix tcl error in jit-elf-helpers.exp
When running test-case jit-elf.exp with target board cc-with-gdb-index, I run
into:
...
gdb compile failed, outputs/gdb.base/jit-elf/.tmp/jit-elf-main-attach: \
No such file or directory.
ERROR: tcl error sourcing src/gdb/testsuite/gdb.base/jit-elf.exp.
ERROR: can't read "main_basename": no such variable
while executing
"untested "failed to compile ${main_basename}.c""
(procedure "compile_jit_main" line 7)
...
The problem is in compile_jit_main in lib/jit-elf-helpers.exp, where we try to
emit an untested message using global variable main_basename.c.
Fixing this by declaring the variable global results in duplicate test-names,
because the same source file is compiled more than once.
Instead, fix this by using the result name in the untested message.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-12 Tom de Vries <tdevries@suse.de>
* lib/jit-elf-helpers.exp: Don't use undefined variables in untested
messages.
Tom de Vries [Tue, 12 May 2020 09:05:44 +0000 (11:05 +0200)]
[gdb/testsuite] Fix duplicate test-names in gdb.ada
In gdb.ada we have these duplicate test-names:
...
DUPLICATE: gdb.ada/catch_ex.exp: continuing to program completion
DUPLICATE: gdb.ada/mi_catch_ex.exp: breakpoint at main
DUPLICATE: gdb.ada/mi_catch_ex.exp: mi runto main
DUPLICATE: gdb.ada/mi_catch_ex_hand.exp: breakpoint at main
DUPLICATE: gdb.ada/mi_catch_ex_hand.exp: mi runto main
...
Fix these using with_test_prefix.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-12 Tom de Vries <tdevries@suse.de>
* gdb.ada/catch_ex.exp: Use with_test_prefix.
* gdb.ada/mi_catch_ex.exp: Same.
* gdb.ada/mi_catch_ex_hand.exp: Same.
Tom de Vries [Tue, 12 May 2020 08:45:20 +0000 (10:45 +0200)]
[gdb/testsuite] Fix duplicate test-names in gdb.trace
In gdb.trace we have these duplicates:
...
DUPLICATE: gdb.trace/passcount.exp: 4.20a: set all three passcounts to three
DUPLICATE: gdb.trace/passcount.exp: 4.6: set passcount to zero
DUPLICATE: gdb.trace/passcount.exp: 4.7: set passcount to large number (32767)
...
Tom de Vries [Tue, 12 May 2020 08:28:44 +0000 (10:28 +0200)]
[gdb/testsuite] Fix duplicate test-names in gdb.{gdb,opt,xml}
There are 3 test directories with one duplicate test-name: gdb.gdb, gdb.opt
and gdb.xml. The duplicates are:
...
DUPLICATE: gdb.gdb/complaints.exp: call complaint_internal ($cstr)
DUPLICATE: gdb.opt/inline-locals.exp: info locals above bar 2 \
(PRMS: gdb/25695)
DUPLICATE: gdb.xml/tdesc-regs.exp: ptype $extrareg
...
Fix as appropriate.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-12 Tom de Vries <tdevries@suse.de>
* gdb.gdb/complaints.exp: Use with_test_prefix.
* gdb.xml/tdesc-regs.exp: Same.
* gdb.opt/inline-locals.exp: Fix test name.
Mihails Strasuns [Tue, 18 Feb 2020 11:30:54 +0000 (12:30 +0100)]
[gdb/testsuite] add jit-elf-util.h and run jit function
Splits ELF related symbols into a separate jit-elf-util.h header and
enhances it with a few more.
Intention is to make adding new JIT tests possible without repeating
most of the common boilerplate.
As a test enhancement, jit-elf-main.c now calls the renamed function
after registering the jit object and ensures it returns an expected
result.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base/jit-elf-util.h: New header file.
* gdb.base/jit-elf-main.c: Use jit-elf-util.h, add a call to
the renamed JIT function to verify its result.
Mihails Strasuns [Fri, 27 Mar 2020 10:21:01 +0000 (11:21 +0100)]
[gdb/testsuite] define jit function name via macro
Replaces previous approach with patching resulting ELF binary after
loading - now that each test iteration works on a separately compiled
binary it is not necessary anymore.
Tests are still being ran without debug info to preserve original test
functionality but this change opens up the possibility to enable debug
info if needed too.
gdb/testsuite/ChangeLog:
2020-03-27 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: Supply -DFUNCTION_NAME macro
definition when compiling jit-elf-solib.co.
* gdb.base/jit-elf-main.c: Stop patching jit function name.
* gdb.base/jit-elf-solib.c: Use FUNCTION_NAME macro value as a
function name.
Mihails Strasuns [Mon, 17 Feb 2020 10:36:47 +0000 (11:36 +0100)]
[gdb/testsuite] use -Ttext-segment for jit-elf tests
Removes the need to manually relocate loaded ELF binary by using a fixed
constant as both mmap base address and as a requested first segment
address supplied to the linker.
In future will enable JIT tests with a valid DWARF debug info. Current
tests still need to compile without a debug info though, because they do
a function name modification.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: Supply -Ttext-segment linker flag and
define LOAD_ADDRESS/LOAD_INCREMENT macros for the compiled binaries.
* gdb.base/jit-elf-main.c: Use LOAD_ADDRESS/LOAD_INCREMENT to
calculate the mmap address.
Mihails Strasuns [Mon, 17 Feb 2020 10:24:14 +0000 (11:24 +0100)]
[gdb/testsuite] add lib/jit-elf-helpers.exp
New utility library to be used by jit-elf tests responsible for
compiling binary artifacts. In the next commit the compilation process
will become more complicated because of extra mandatory flag - keeping
it in one place will make tests less fragile.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* lib/jit-elf-helpers.exp: New file.
* gdb.base/jit-elf.exp: Updated to use jit-elf-helpers.exp.
* gdb.base/jit-elf-so.exp: Updated to use jit-elf-helpers.exp.
[gdb/testsuite] use args as lib list for jit-elf tests
Old usage: jit-elf-main lib.so 2
New usage: jit-elf-main lib.so.1 lib.so.2
Refactoring necessary to support running tests over multiple jit
binaries rather than mapping the same binary muultiple times.
gdb/testsuite/ChangeLog:
2020-02-18 Mihails Strasuns <mihails.strasuns@intel.com>
* gdb.base/jit-elf-main.c: Read lib list from argc/argv.
* gdb.base/jit-elf.exp: Compile N jit libraries and use the list.
* gdb.base/jit-elf-so.exp: Ditto.
Tom de Vries [Tue, 12 May 2020 07:47:15 +0000 (09:47 +0200)]
[gdb/testsuite] Fix duplicate test-names in gdb.dwarf2
We currently have these duplicate test-names in gdb.dwarf2:
...
$ grep ^DUPLICATE: gdb.sum
DUPLICATE: gdb.dwarf2/comp-unit-lang.exp: show language
DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)"
DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (void *)"
DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)"
DUPLICATE: gdb.dwarf2/data-loc.exp: get integer valueof "sizeof (int)"
DUPLICATE: gdb.dwarf2/data-loc.exp: ptype foo.array_type
DUPLICATE: gdb.dwarf2/varval.exp: get integer valueof "sizeof (int)"
DUPLICATE: gdb.dwarf2/varval.exp: get integer valueof "sizeof (void *)"
DUPLICATE: gdb.dwarf2/implref-struct.exp: print-object=off: \
set print object off
DUPLICATE: gdb.dwarf2/implref-struct.exp: print-object=on: \
set print object on
DUPLICATE: gdb.dwarf2/dw2-bad-parameter-type.exp: ptype f
...
Fix as appropriate.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-12 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/comp-unit-lang.exp: Use with_test_prefix.
* gdb.dwarf2/dw2-bad-parameter-type.exp: Same.
* gdb.dwarf2/implref-struct.exp: Same.
* gdb.dwarf2/varval.exp: Ensure get_sizeof is called once per type.
* gdb.dwarf2/data-loc.exp: Same. Remove duplicate test.
Tom Tromey [Mon, 11 May 2020 21:28:12 +0000 (15:28 -0600)]
Restore info_command and breakpoint
As discussed on gdb-patches, this restores info_command and the
breakpoint on info_command in gdb-gdb.gdb. This reverts a tiny part
of 0743fc83c03 ("Replace most calls to help_list and cmd_show_list"),
as well as 652fc23a30a ("Remove gdb-gdb.gdb breakpoint on disappeared
function info_command.").
gdb/ChangeLog
2020-05-11 Tom Tromey <tromey@adacore.com>
* cli/cli-cmds.c (info_command): Restore.
(_initialize_cli_cmds): Use add_prefix_command for "info".
* gdb-gdb.gdb.in: Restore breakpoint on info_command.
Andrew Burgess [Thu, 23 Apr 2020 14:19:15 +0000 (15:19 +0100)]
gdb/testsuite: Detect and warn about duplicate test names
Building on the previous commit, this patch detects when two tests
have the same test name and causes Dejagnu to print a new result type
'# of duplicate test names' in the result summary. A line starting
with 'DUPLICATE: ' is also added to the gdb.sum and gdb.log files.
The DUPLICATE markers will be printed the second time a duplicate test
name is seen, and every time after that. So you might see:
However, the results will report a duplicate count of 1, indicating
that just one test name (foo) was duplicated.
Currently if the tests are run in parallel mode the new result type is
not merged into the combined summary file so users will need to run in
non-parallel mode to check this result. Similarly, the 'DUPLICATE: '
markers will not be merged into the final gdb.sum file. A later
commit will fix this.
gdb/testsuite/ChangeLog:
* lib/check-test-names.exp (all_test_names): New module variable.
(counts): Add 'duplicates' field.
(_check_duplicates): New procedure.
(check): Also check for duplicates.
(do_log_summary): Print duplicates count.
(do_reset_vars): Reset counter for duplicate test names, and
discard all know test names.
Andrew Burgess [Thu, 23 Apr 2020 09:47:29 +0000 (10:47 +0100)]
gdb/testsuite: Detect and warn if paths are used in test names
A new library is introduced that hooks into the core of Dejagnu and
detects when a test's name includes either the source or build paths.
If any offending test names are detected then Dejagnu will print a
new result type, '# of paths in test names'. Users should treat this
result type just like other bad results types, and aim not to increase
this number.
As well as displaying the total number of offending tests as part of
the final results, a new marker is included in both the gdb.log and
gdb.sum files, this marker starts with 'PATH: ', so an offending test
would be expected to appear like this:
This should make it easier to track down offending tests.
Currently for a local run on my machine, I don't see any offending
test names, but it is possible that different targets, or different
configurations, might currently be breaking the no paths rule.
In order to get this working I have needed to wrap two core Dejagnu
functions, log_summary, and reset_vars. Relying on core functions
that are not part of any API is always going to be risky, given the
relatively slow rate of Dejagnu change this is probably OK for now,
and we can possibly upstream some changes to Dejagnu that would allow
this functionality to be supported in a more official way later on.
Currently if the tests are run in parallel mode the new result type is
not merged into the combined summary file so users will need to run in
non-parallel mode to check this result. Similarly, the 'PATH: '
markers will not be merged into the combined summary file. A later
commit will fix this.
gdb/testsuite/ChangeLog:
* lib/gdb.exp: Include check-test-names.exp library.
* lib/check-test-names.exp: New file.
Tom Tromey [Mon, 11 May 2020 20:57:49 +0000 (14:57 -0600)]
Fix Ada value printing on PPC64
The val_print removal patches introduced an Ada regression on PPC64
(probably any big-endian system).
The issue comes because value_field does not understand that Ada
wrapper fields can be bitfields that wrap a non-scalar type. In this
case the value is already left-justified, so the justification done
there does the wrong thing.
Perhaps it would be good, eventually, to change value_field to
understand this case. In the meantime this implements an Ada-specific
solution.
gdb/ChangeLog
2020-05-11 Tom Tromey <tromey@adacore.com>
* ada-lang.c (ada_value_primitive_field): Now public.
* ada-lang.h (ada_value_primitive_field): Declare.
* ada-valprint.c (print_field_values): Use
ada_value_primitive_field for wrapper fields.
When running tests using RUNTESTFLAGS="cpexprs.exp cpexprs-debug-types.exp",
we have:
...
Running src/gdb/testsuite/gdb.cp/cpexprs-debug-types.exp ...
Running src/gdb/testsuite/gdb.cp/cpexprs.exp ...
...
In the first test-case, we have -fdebug-types-section as expected:
...
Running src/gdb/testsuite/gdb.cp/cpexprs-debug-types.exp ...
g++ -fno-stack-protector -fdiagnostics-color=never \
-fdebug-types-section \
-c -g \
-o outputs/gdb.cp/cpexprs-debug-types/cpexprs-debug-types0.o \
src/gdb/testsuite/gdb.cp/cpexprs.cc
...
but in the second test-case, we have also have -fdebug-types-section:
...
Running src/gdb/testsuite/gdb.cp/cpexprs.exp ...
g++ -fno-stack-protector -fdiagnostics-color=never \
-fdebug-types-section \
-c -g -g \
-o outputs/gdb.cp/cpexprs/cpexprs0.o \
src/gdb/testsuite/gdb.cp/cpexprs.cc
...
This is due to using a global variable flags, which is set in
cpexprs-debug-types.exp and tested for existence in cpexprs.exp.
Fix this by using a more robust inclusion mechanism, that is:
- move the bulk of the test-case cpexprs.exp to cpexprs.exp.in,
- include it from cpexprs.exp and cpexprs-debug-types.exp, and
- set flags in both .exp files
gdb/testsuite/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
* gdb.cp/cpexprs.exp: Move everything except flags setting ...
* gdb.cp/cpexprs.exp.in: .. here.
* gdb.cp/cpexprs-debug-types.exp: Include cpexprs.exp.in instead of
cpexprs.exp.
Tom de Vries [Mon, 11 May 2020 15:13:49 +0000 (17:13 +0200)]
[gdb/symtab] Save modules in .debug_names
When running test-case gdb.fortran/info-modules.exp with target board
debug-names, I run into:
...
FAIL: gdb.fortran/info-modules.exp: info modules: check for entry \
'info-types-2.f90', '18', 'mod2'
...
In more detail, comparing the behaviour of the executable without and with
.debug_names section, we have:
...
-$ gdb -batch info-modules -ex "info modules"
+$ gdb -batch info-modules.debugnames -ex "info modules"
All defined modules:
When loading this exec into gdb, we run into this assert:
...
$ gdb a.out
Reading symbols from a.out...
warning: Section .debug_aranges in a.out entry at offset 0 \
debug_info_offset 0 does not exists, ignoring .debug_aranges.
src/gdb/dwarf2/read.c:6949: \
internal-error: cutu_reader::cutu_reader(dwarf2_per_cu_data*, \
abbrev_table*, int, bool): \
Assertion `this_cu->length == cu->header.get_length ()' failed.
...
The problem is that the determined length of the CU:
...
(gdb) p /x this_cu->length
$4 = 0x26a
...
does not match the actual length:
...
(gdb) p /x cu->header.get_length ()
$5 = 0x59
...
The length of the CU is determined in create_cus_from_debug_names_list, and
set based on this list in the .debug_names section:
...
Compilation Unit offsets [
CU[0]: 0x000000c7
]
...
and it is assumed that this is a complete list, so the size of the CU is
calculated using the end of the .debug_section at 0x331, making it 0x331 -
0xc7 == 0x26a.
However, the CU list is not complete:
...
$ llvm-dwarfdump -debug-info a.out \
| grep "Compile Unit" \
| sed 's/Compile Unit.*//'
0x00000000:
0x0000002e:
0x000000a5:
0x000000c7:
0x00000120:
0x00000157:
0x0000030f:
...
In particular, because the CU for foo.c is there at 0x120 (the rest of the CUs
is due to openSUSE having debug info for various linked in objects).
Fix the assert by not assuming to know the length of CUs in
create_cus_from_debug_names_list (if the .debug_names is not produced by GDB),
and setting it to 0, and setting it later to the actual length.
Note that this does not fix the .debug_aranges warning, that's PR25969.
Build and tested on x86_64-linux, with native and debug-names.
gdb/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
PR symtab/25941
* dwarf2/read.c (create_cus_from_debug_names_list): Initialize CUs
with length 0, if not gdb-produced.
(cutu_reader::cutu_reader): Set CU length to actual length if 0.
gdb/testsuite/ChangeLog:
2020-05-11 Tom de Vries <tdevries@suse.de>
PR symtab/25941
* gdb.dwarf2/clang-debug-names.exp.in: New include exp file, factored
out of ...
* gdb.dwarf2/clang-debug-names.exp: ... here.
* gdb.dwarf2/clang-debug-names-2.exp: New file. Include
clang-debug-names.exp.in.
* gdb.dwarf2/clang-debug-names-2-foo.c: New test.
* gdb.dwarf2/clang-debug-names-2.c: New test.
Peter Bergner [Mon, 11 May 2020 00:01:40 +0000 (09:31 +0930)]
Power10 byte reverse instructions
opcodes/
* ppc-opc.c (powerpc_opcodes) <brd, brh, brw>: New mnemonics.
gas/
* testsuite/gas/ppc/byte_rev.d,
* testsuite/gas/ppc/byte_rev.s: New test.
* testsuite/gas/ppc/ppc.exp: Run it.
Peter Bergner [Sun, 10 May 2020 23:57:48 +0000 (09:27 +0930)]
Power10 Add new L operand to the slbiag instruction
opcodes/
* ppc-opc.c (powerpc_opcodes) <slbiag>: Add variant with L operand.
gas/
* testsuite/gas/ppc/power10.s: New test.
* testsuite/gas/ppc/power10.d: Likewise.
* testsuite/gas/ppc/ppc.exp: Run it.
Alan Modra [Mon, 11 May 2020 08:30:31 +0000 (18:00 +0930)]
PR25961, buffer overflow in coff_swap_aux_in
PR 25961
* coffgen.c (coff_get_normalized_symtab): Check that buffer
contains required number of auxents before processing any auxent.
* coffswap.h (coff_swap_aux_in <C_FILE>): Only swap in extended
file name from auxents for PE.
Name of fortran main function for Flang compiler is MAIN_ while
for gfortran it is MAIN__ . In test cases MAIN__ is hardcoded for
the purpose of inserting breakpoint.
New proc is added to detect main function name depending on the
compiler used.
Fortran specific version of runto_main named fortran_runto_main
is added.
This commit adds support for Flang main function, there should be
no change for gfortran.
Tom de Vries [Sat, 9 May 2020 18:17:10 +0000 (20:17 +0200)]
[gdb] Fix catch throw regexp matching
When running test-case gdb.mi/mi-catch-cpp-exceptions.exp, we have:
...
FAIL: gdb.mi/mi-catch-cpp-exceptions.exp: all with invalid regexp: run until \
breakpoint in main (unknown output after running)
...
This is a regression since commit 596dc4adff "Speed up psymbol reading by
removing a copy".
Before that commit, we have:
...
$ gdb \
-batch \
./outputs/gdb.mi/mi-catch-cpp-exceptions/mi-catch-cpp-exceptions \
-ex "break 67" \
-ex "catch throw -r blahblah" \
-ex r
Breakpoint 1 at 0x4008e5: file mi-catch-cpp-exceptions.cc, line 67.
Catchpoint 2 (throw)
Breakpoint 1, main () at mi-catch-cpp-exceptions.cc:67
67 return 1; /* Stop here. */
...
In other words:
- we set a breakpoint somewhere in main,
- we set a catchpoint with a regexp that is intended to not match any
exception, and
- run to the breakpoint, without the catchpoint triggering.
After the commit, we have:
...
$ gdb \
-batch \
./outputs/gdb.mi/mi-catch-cpp-exceptions/mi-catch-cpp-exceptions \
-ex "break 67" \
-ex "catch throw -r blahblah" \
-ex r
Breakpoint 1 at 0x4008e5: file mi-catch-cpp-exceptions.cc, line 67.
Catchpoint 2 (throw)
Catchpoint 2 (exception thrown), 0x00007ffff7ab037e in __cxa_throw () from \
/usr/lib64/libstdc++.so.6
...
In other words, the catchpoint triggers.
This is caused by this bit of the commit:
...
type_name = cplus_typename_from_type_info (typeinfo_arg);
- if (!type_name.empty ())
+ if (name != nullptr)
{
- if (self->pattern->exec (type_name.c_str (), 0, NULL, 0) != 0)
+ if (self->pattern->exec (name, 0, NULL, 0) != 0)
...
Before the commit, we have:
- type_name == "my_exception"
- canon = ""
and the !type_name.empty () test succeeds, and gdb executes the
self->pattern->exec call.
After the commit, we have:
- type_name == "my_exception"
- canon == NULL
- name == NULL
and the name != nullptr test fails, and gdb doesn't execute the
self->pattern->exec call.
Fix this by inverting the condition for the calculation of name:
...
- name = (canon == nullptr
+ name = (canon != nullptr
...
Build and tested on x86_64-linux.
gdb/ChangeLog:
2020-05-09 Tom de Vries <tdevries@suse.de>
PR gdb/25955
* break-catch-throw.c (check_status_exception_catchpoint): Fix name
calculation.
nitachra [Sat, 9 May 2020 08:03:51 +0000 (10:03 +0200)]
Fix for the complaint observed when symbol reading due to unsupported .debug_names form
Following complaint is observed with the executable compiled with -gdwarf-5
and -gpubnames flags - "During symbol reading: Unsupported .debug_names form
DW_FORM_ref4". This is the form corresponding to DW_IDX_die_offset attribute.
This patch fixes this complaint. Tested with clang 10.0.0. Test case used -
int main()
{
int sum,a,b;
sum = a + b;
return sum;
}
Reading symbols from test.out...
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
[in module test.out]
Temporary breakpoint 1 at 0x400484
Starting program: test.out
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
[in module test.out]
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
[in module test.out]
During symbol reading: Unsupported .debug_names form DW_FORM_ref4 \
[in module test.out]
gdb/dwarf2/ChangeLog:
2020-05-09 Nitika Achra <Nitika.Achra@amd.com>
PR symtab/25952
* read.c (dw2_debug_names_iterator::next): Handle DW_FORM_ref*
and DW_IDX_die_offset. If there is no compilation unit attribute in
the index entry, then there is a single CU. Return the CU at O index
of compilation unit vector.
Tom Tromey [Fri, 8 May 2020 20:26:11 +0000 (14:26 -0600)]
Don't re-process a DIE in read_lexical_block_scope
A customer reported a crash in the DWARF reader.
Investigation showed that the crash occurred in an unusual scenario: a
function was lexically scoped within some other function -- but the
inner function inlined the outer function and referred to its DIE via
DW_AT_abstract_origin. With the executable in question,
inherit_abstract_dies could eventually call read_lexical_block_scope,
which in turn could recurse into process_die, to process a DIE that
was already being read, triggering an assert.
However, in this case, I don't have an easy way to reproduce. So,
there is no test case.
I did experiment with the failing executable. This patch fixes the
bug and doesn't seem to cause other issues. For example, I can still
set breakpoints on the relevant functions.
gdb/ChangeLog
2020-05-08 Tom Tromey <tromey@adacore.com>
* dwarf2/read.c (read_lexical_block_scope): Don't process a DIE
already being processed.
Tom Tromey [Fri, 8 May 2020 20:21:22 +0000 (14:21 -0600)]
More C++-ification for struct display
This changes displays to have a constructor, use bool and std::string,
and to be stored using std::vector. The ALL_DISPLAYS and
ALL_DISPLAYS_SAFE macros are removed. While internal iteration is
still done via map_display_numbers, this is updated to use a
function_view. These changes simplify the code somewhat; for example,
free_display can now be removed in favor of ordinary destruction.
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
* printcmd.c (struct display) <next>: Remove.
<display>: New constructor.
<exp_string>: Now a std::string.
<enabled_p>: Now a bool.
(display_number): Move definition earlier.
(displays): Rename from display_chain. Now a std::vector.
(ALL_DISPLAYS, ALL_DISPLAYS_SAFE): Remove.
(display_command): Update.
(do_one_display, disable_display)
(enable_disable_display_command, do_enable_disable_display):
Update.
(free_display): Remove.
(clear_displays): Rewrite.
(delete_display): Update.
(map_display_numbers): Use function_view. Remove "data"
parameter. Update.
(do_delete_display): Remove.
(undisplay_command): Update.
(do_one_display, do_displays, disable_display)
(info_display_command): Update.
(do_enable_disable_display): Remove.
(enable_disable_display_command)
(clear_dangling_display_expressions): Update.
Tom Tromey [Fri, 8 May 2020 20:21:22 +0000 (14:21 -0600)]
Remove ALL_PSPACES
This removes the ALL_PSPACES macro. In this case it seemed cleanest
to change how program spaces are stored -- instead of using a linked
list, they are now stored in a std::vector.
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 8 May 2020 20:21:22 +0000 (14:21 -0600)]
Remove ALL_SO_LIBS and so_list_head
This patch started as an attempt to replace ALL_SO_LIBS with an
ordinary C++ iterator. However, then I tripped over the so_list_head
define again, and decided to remove it as well.
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 8 May 2020 20:21:22 +0000 (14:21 -0600)]
Remove ALL_EXTENSION_LANGUAGES and ALL_ENABLED_EXTENSION_LANGUAGES
This removes the ALL_EXTENSION_LANGUAGES and
ALL_ENABLED_EXTENSION_LANGUAGES macros, in favor of ordinary
iterators. For ALL_ENABLED_EXTENSION_LANGUAGES, I chose to simply
inline the check, as that seemed simpler than trying to make
filtered_iterator work for std::array. (As an aside, this sort of
thing will be easier once we can use the ranges library...)
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
Tom Tromey [Fri, 8 May 2020 20:14:05 +0000 (14:14 -0600)]
Speed up psymbol reading by removing a copy
I noticed that cp_canonicalize_string and friends copy a
unique_xmalloc_ptr to a std::string. However, this copy isn't
genuinely needed anywhere, and it serves to slow down DWARF psymbol
reading.
This patch removes the copy and updates the callers to adapt.
This speeds up the reader from 1.906 seconds (mean of 10 runs, of gdb
on a copy of itself) to 1.888 seconds (mean of 10 runs, on the same
copy as the first trial).
gdb/ChangeLog
2020-05-08 Tom Tromey <tom@tromey.com>
Tom de Vries [Fri, 8 May 2020 15:26:32 +0000 (17:26 +0200)]
[gdb] Fix stepping over fork with follow-fork-mode child and gcc-8
When running test-case gdb.threads/fork-child-threads.exp with gcc-8 instead
of gcc-7, we have:
...
(gdb) next^M
[Attaching after Thread 0x7ffff7fae740 (LWP 27574) fork to child process \
27578]^M
[New inferior 2 (process 27578)]^M
[Detaching after fork from parent process 27574]^M
[Inferior 1 (process 27574) detached]^M
[Thread debugging using libthread_db enabled]^M
Using host libthread_db library "/lib64/libthread_db.so.1".^M
[Switching to Thread 0x7ffff7fae740 (LWP 27578)]^M
-main () at src/gdb/testsuite/gdb.threads/fork-child-threads.c:41^M
+main () at src/gdb/testsuite/gdb.threads/fork-child-threads.c:34^M
-41 i = pthread_create (&thread, NULL, start, NULL);^M
+34 switch (fork ())^M
-(gdb) PASS: gdb.threads/fork-child-threads.exp: next over fork
+(gdb) FAIL: gdb.threads/fork-child-threads.exp: next over fork
...
This is due to the fact that gcc-8 generates more precise line info, making
the instruction after the call to fork a "recommended breakpoint location".
However, it is a bug because next is supposed to move to the next source
line.
The problem is that in process_event_stop_test we hit this code:
...
if ((ecs->event_thread->suspend.stop_pc == stop_pc_sal.pc)
&& (ecs->event_thread->current_line != stop_pc_sal.line
|| ecs->event_thread->current_symtab != stop_pc_sal.symtab))
{
if (stop_pc_sal.is_stmt)
{
/* We are at the start of a different line. So stop. Note that
we don't stop if we step into the middle of a different line.
That is said to make things like for (;;) statements work
better. */
if (debug_infrun)
fprintf_unfiltered (gdb_stdlog,
"infrun: stepped to a different line\n");
end_stepping_range (ecs);
return;
}
...
because current_line and current_symtab have initial values:
...
(gdb) p ecs->event_thread->current_line
$8 = 0
(gdb) p ecs->event_thread->current_symtab
$9 = (symtab *) 0x0
...
Fix this in follow_fork by copying current_line and current_symtab from
parent thread to child thread.
Tested on x86_64-linux, with gcc 7.5.0 and gcc 10.0.1.
gdb/ChangeLog:
2020-05-08 Tom de Vries <tdevries@suse.de>
* infrun.c (follow_fork): Copy current_line and current_symtab to
child thread.
Add test-case with .debug_names section using DW_FORM_ref4.
There's currently no support for .debug_names in the dwarf assembler, so we
use plain _emit rather than something more structured.
Consequently, we cannot use regular declare_labels-generated labels to refer
from .debug_names to .debug_info. Instead, we use labels with a
predefined name, which we generate using _compute_label, and then define using
define_label.
This is the test-case for PR25952, so kfail the corresponding test.
Tested on x86_64-linux.
gdb/testsuite/ChangeLog:
2020-05-08 Tom de Vries <tdevries@suse.de>
* gdb.dwarf2/clang-debug-names.c: New test.
* gdb.dwarf2/clang-debug-names.exp: New file.
Simon Marchi [Thu, 7 May 2020 15:18:42 +0000 (11:18 -0400)]
gdb: remove TYPE_DYN_PROP_LIST macro
Remove this macro, which abstracts how to obtain the dyn_prop_list of a
given type. We could replace it with a method on `struct type`, but I
don't think it's needed, as the only code that accesses the dynamic prop
list directly is internal gdbtypes.c code (that can be seen as code
internal to `struct type`). So it can just refer to the field directly.
gdb/ChangeLog:
* gdbtypes.h (TYPE_DYN_PROP_LIST): Remove. Update all users
access thistype->main_type->dyn_prop_list directly.
projects / thirdparty / binutils-gdb.git / log
