bfd/ChangeLog:
2020-07-21 Jon Turney <jon.turney@dronecode.org.uk>
* elf.c (elfcore_grok_win32pstatus): Warn on malformed
win32pstatus notes, and return TRUE so we continue rather than
stopping as if it was an error.
Don't reject any win32pstatus notes smaller than minimum size for a
NOTE_INFO_THREAD.
This only happens to work because the Cygwin dumper tool currently
writes all these notes as the largest size of the union, (which wastes
lots of space in the core dump).
Instead, apply the appropriate size constraint for each win32pstatus
note type.
bfd/ChangeLog:
2020-07-11 Jon Turney <jon.turney@dronecode.org.uk>
* elf.c (elfcore_grok_win32pstatus): Don't apply size constraint
for NOTE_INFO_THREAD to all win32pstatus ELF notes, instead apply
appropriate size constraint for each win32pstatus note type.
Don't hardcode the size of the Win32 API thread CONTEXT type read from a
NOTE_INFO_THREAD win32pstatus note (since it's different on different
architectures).
bfd/ChangeLog:
2020-07-01 Jon Turney <jon.turney@dronecode.org.uk>
* elf.c (elfcore_grok_win32pstatus): Don't hardcode the size of
the Win32 API thread CONTEXT type read from a NOTE_INFO_THREAD
win32pstatus note.
Define constants for win32pstatus ELF notes, as they were prior to
4a6636fb, and say what specifies them.
bfd/ChangeLog:
2020-07-11 Jon Turney <jon.turney@dronecode.org.uk>
* elf.c (NOTE_INFO{_PROCESS,_THREAD,_MODULE}): Define.
(elfcore_grok_win32pstatus): Use.
Fix the offset used to read the tid from a win32pstatus ELF note.
This probably meant that registers were only being correctly recovered
from the core dump for the current thread.
It looks like this has beeen incorrect since 4a6636fb.
Also fix offsets used in NOTE_INFO_PROCESS (which is not actually
generated by the Cygwin dumper tool).
Also improve comment.
bfd/ChangeLog:
2020-07-01 Jon Turney <jon.turney@dronecode.org.uk>
* elf.c (elfcore_grok_win32pstatus): Fix the offset used to read
the tid from a win32pstatus NOTE_INFO_THREAD ELF note. Fix
offsets used to read NOTE_INFO_PROCESS.
gdb.dwarf2/dw2-op-out-param.S contained a duplicate label, and failed
to build with clang with the following error:
gdb compile failed, /gdbtest/src/gdb/testsuite/gdb.dwarf2/dw2-op-out-param.S:163:1:
error: invalid symbol redefinition
.Ltext5:
^
This commit renames the two labels as .Ltext5a and .Ltext5b, and
updates all references appropriately.
gdb/testsuite/ChangeLog:
* gdb.dwarf2/dw2-op-out-param.S (.Ltext5): Fix duplicate label.
This patch adds support for the system registers introduced in the
Armv8-A MPAM extension.
See https://developer.arm.com/documentation/ddi0598/latest for the
Arm ARM supplement documenting this extension.
gas/ChangeLog:
* testsuite/gas/aarch64/mpam-bad.d: New test.
* testsuite/gas/aarch64/mpam-bad.l: Error output.
* testsuite/gas/aarch64/mpam-bad.s: Input.
* testsuite/gas/aarch64/mpam.d: New test.
* testsuite/gas/aarch64/mpam.s: Input.
opcodes/ChangeLog:
* aarch64-opc.c (aarch64_sys_regs): Add MPAM registers.
PR binutils/26331
* readelf.c (do_demangle): New option flag.
(print_symbol): If do_demangle is enabled, demangle the symbol.
(enum long_option_values): New enum to hold long option values.
(options): Add demangle, no-demangle, recursion-limit and
no-recursion-limit options. Alpha sort the table.
(usage): Describe the new options.
(parse_args): Handle the new options.
* NEWS: Mention the new feature.
* doc/binutils.texi: Document the new feature.
* testsuite/binutils-all/readelf.exp: Test the new feature.
* testsuite/binutils-all/mangled.s: New file - assembler source.
* testsuite/binutils-all/readelf.demangled: New file - expected
output from readelf.
When running gdb/gdb_mbuild.sh, we run into:
...
ms1-elf ...
... src/configure --target=ms1-elf --enable-gdb-build-warnings=,-Werror \
--enable-sim-build-warnings=,-Werror
... make -k -j 5 ms1-elf
ms1-elf: compile failed
...
In mbuild/ms1-elf/Build.log we find:
...
*** Configuration mt-unknown-elf is obsolete.
*** Support has been REMOVED.
make: *** [Makefile:10995: configure-gdb] Error 1
...
The support for ms1-elf, aka mt-elf, has been removed since commit dc71152484
"Remove mt port" in Jan 2018. Make this official in the MAINTAINERS file.
Tested using gdb/gdb_mbuild.sh.
gdb/ChangeLog:
2020-08-11 Tom de Vries <tdevries@suse.de>
* MAINTAINERS: Mark ms1 as deleted.
This patch fixes an assertion failure on long system register operands
in the AArch64 backend. See the new testcase for an input which
reproduces the issue.
gas/ChangeLog:
* config/tc-aarch64.c (parse_sys_reg): Don't assert when parsing
a long system register.
(parse_sys_ins_reg): Likewise.
(sysreg_hash_insert): New.
(md_begin): Use sysreg_hash_insert() to ensure all system
registers are no longer than the maximum length at startup.
* testsuite/gas/aarch64/invalid-sysreg-assert.d: New test.
* testsuite/gas/aarch64/invalid-sysreg-assert.l: Error output.
* testsuite/gas/aarch64/invalid-sysreg-assert.s: Input.
include/ChangeLog:
* opcode/aarch64.h (AARCH64_MAX_SYSREG_NAME_LEN): New.
When running gdb/gdb_mbuild.sh, I run into:
...
src/sim/aarch64/../common/sim-cpu.c: In function 'sim_cpu_free':
src/sim/aarch64/../common/sim-cpu.c:64:3: error: implicit declaration of \
function 'free' [-Werror=implicit-function-declaration]
free (cpu);
^~~~
src/sim/aarch64/../common/sim-cpu.c:64:3: error: incompatible implicit \
declaration of built-in function 'free' [-Werror]
src/sim/aarch64/../common/sim-cpu.c:64:3: note: include '<stdlib.h>' or \
provide a declaration of 'free'
...
Fix this by adding "#include <stdlib.h>".
Tested by gdb/gdb_mbuild.sh -e aarch64-elf.
sim/common/ChangeLog:
2020-08-10 Tom de Vries <tdevries@suse.de>
* sim-cpu.c: Include stdlib.h for free.
I initially noticed the problem with the addition of
gdb.dwarf2/dw2-line-number-zero.exp. The following failures showed up:
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar1
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 1st next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar1, 2nd next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: continue to breakpoint: bar2
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 1st next
FAIL: gdb.dwarf2/dw2-line-number-zero.exp: bar2, 2nd next
They happen because AArch64's prologue analyzer skips too many instructions
and ends up indicating a stopping point further into user code.
Dump of assembler code for function bar1:
0x00000000000006f8 <+0>: stp x29, x30, [sp, #-16]!
0x00000000000006fc <+4>: mov x29, sp
0x0000000000000700 <+8>: mov w0, #0x1 // #1
0x0000000000000704 <+12>: bl 0x6e4 <foo>
0x0000000000000708 <+16>: mov w0, #0x2 // #2
We should've stopped at 0x700, but the analyzer actually skips
that instruction and stops at 0x704. Then GDB ends up adjusting
the address further, and pushes the stopping point to 0x708 based on the
SAL information.
I'm not sure if this adjustment to 0x708 is correct though, as it ends up
skipping past a branch. But I'm leaving that aside for now.
One other complicating factor is that GCC seems to be hoisting up instructions
from user code, mixing them up with prologue instructions.
The following patch adjusts the heuristics a little bit, and tracks when the
SP and FP get used. If we notice an instruction that is not supposed to be
in the prologue, and this happens *after* SP/FP adjustments and saving of
registers, we stop the analysis.
This means, for PR26310, that we will now stop at 0x700.
I've also added a few more unit tests to make sure the updated behavior is
validated.
gdb/ChangeLog:
2020-08-10 Luis Machado <luis.machado@linaro.org>
PR gdb/26310
* aarch64-tdep.c (aarch64_analyze_prologue): Track use of SP/FP and
act accordingly.
(aarch64_analyze_prologue_test): Add more unit tests to exercise
movz/str/stur/stp skipping behavior.
The kernel has fixed this here:
https://lore.kernel.org/patchwork/patch/1029011/
We should do the same for GDB, which is still carrying an incorrect
definition of the macro. As stated in the kernel patch thread, this doesn't
actually change things because, luckily, the structs are of the same size.
gdb/ChangeLog:
2020-08-10 Luis Machado <luis.machado@linaro.org>
* nat/aarch64-sve-linux-sigcontext.h (SVE_PT_REGS_OFFSET): Use
struct user_sve_header instead of struct sve_context.
Replace the function pointer + `void *` parameters of
dwarf2_fetch_die_loc_sect_off and dwarf2_fetch_die_loc_cu_off with a
function_view parameter. Change call sites to use a lambda function.
This improves type-safety, so reduces the chances of errors.
gdb/ChangeLog:
* read.h (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off): Replace function pointer +
`void *` parameter with function_view.
* read.c (dwarf2_fetch_die_loc_sect_off,
dwarf2_fetch_die_loc_cu_off): Likewise.
* loc.c (get_frame_pc_for_per_cu_dwarf_call): Remove.
(per_cu_dwarf_call): Adjust.
(get_frame_address_in_block_wrapper): Remove.
(indirect_synthetic_pointer): Adjust.
(get_ax_pc): Remove.
(dwarf2_compile_expr_to_ax): Adjust.
Change-Id: Ic9b6ced0c4128f2b75ca62e0ed638b0962a22859
When building gdb on x86_64-linux with --enable-targets riscv64-suse-linux, I
run into:
...
src/gdb/arch/riscv.c:112:45: required from here
/usr/include/c++/4.8/bits/hashtable_policy.h:195:39: error: no matching \
function for call to 'std::pair<const riscv_gdbarch_features, const \
std::unique_ptr<target_desc, target_desc_deleter> >::pair(const \
riscv_gdbarch_features&, target_desc*&)'
: _M_v(std::forward<_Args>(__args)...) { }
^
...
for this code in riscv_lookup_target_description:
...
/* Add to the cache. */
riscv_tdesc_cache.emplace (features, tdesc);
...
Work around this compiler problem (filed as PR gcc/96537), similar to how that
was done in commit 6d0cf4464e "Fix build with gcc-4.8.x":
...
- riscv_tdesc_cache.emplace (features, tdesc);
+ riscv_tdesc_cache.emplace (features, target_desc_up (tdesc));
...
That is, call the target_desc_up constructor explictly instead of implicitly.
Also, work around a similar issue in get_thread_arch_aspace_regcache.
Build on x86_64-linux with --enable-targets riscv64-suse-linux, and
reg-tested.
gdb/ChangeLog:
2020-08-08 Tom de Vries <tdevries@suse.de>
PR build/26344
* arch/riscv.c (riscv_lookup_target_description): Use an explicit
constructor.
* regcache.c (get_thread_arch_aspace_regcache): Same.
When performing DISP{16,32} relocations, the eBPF ELF backend linker
needs to convert the relocation from an address into a signed number
of 64-bit words (minus one) to jump.
Because of this unsigned-to-signed conversion, special care needs to
be taken when dividing to ensure the sign bits remain correct.
Otherwise, a false relocation overflow error can be triggered.
bfd/ChangeLog
2020-08-07 David Faust <david.faust@oracle.com>
* elf64-bpf.c (bpf_elf_relocate_section): Ensure signed division for
DISP16 and DISP32 relocations.
ld/ChangeLog
2020-08-07 David Faust <david.faust@oracle.com>
* testsuite/ld-bpf/call-3.s: New file.
* testsuite/ld-bpf/call-3.d: Likewise.
Testing showed a few more Ravenscar regressions arising from upstream.
In particular, gdb now uses the current thread in some places where
inferior_ptid was previously used. This patch fixes the problem by
arranging to save and restore the thread now.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c
(ravenscar_thread_target::set_base_thread_from_ravenscar_task):
New method.
(ravenscar_thread_target::wait): Check
runtime_initialized.
(ravenscar_thread_target::prepare_to_store)
(ravenscar_thread_target::stopped_by_sw_breakpoint)
(ravenscar_thread_target::stopped_by_hw_breakpoint)
(ravenscar_thread_target::stopped_by_watchpoint)
(ravenscar_thread_target::stopped_data_address)
(ravenscar_thread_target::core_of_thread): Use
scoped_restore_current_thread and
set_base_thread_from_ravenscar_task.
Commit 2da4b788f ("Don't write to inferior_ptid in
ravenscar-thread.c") caused a Ravenscar regression (which, FWIW, is
understandable because Ravenscar is difficult to test). Namely,
ravenscar_thread_target::update_thread_list calls
iterate_over_live_ada_tasks, which calls ada_build_task_list, which
uses target_has_stack -- which relies on inferior_ptid.
This patch changes update_thread_list to ensure that inferior_ptid is
set before making this call. This avoids various failures on
Ravenscar targets.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (update_thread_list): Set inferior_ptid.
Fabien also noticed that gdb would not report a stop correctly when
using Ravenscar. This patch fixes the bug by making a few changes:
* ravenscar_thread_target::wait now updates the inferior ptid before
updating the thread list. This ensures that a new thread is
correctly associated with the underlying CPU.
* The fetch_registers, store_registers, and prepare_to_store methods
now save and restore the regcache's ptid before doing the operation
on the underlying live thread. This ensures that gdb informs the
remote of a thread it knows about, as opposed to using a Ravenscar
thread, which probably will not be recognized.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target::wait): Call
update_inferior_ptid before update_thread_list.
(temporarily_change_regcache_ptid): New class.
(ravenscar_thread_target::fetch_registers)
(ravenscar_thread_target::store_registers)
(ravenscar_thread_target::prepare_to_store): Use base thread when
forwarding operation.
A coworker noticed that gdb would send the wrong vCont packet to qemu
when debugging a Ravenscar program:
> (gdb) thread 2
> [Switching to thread 2 (Thread 1.2)]
> #0 0x0000000000001000 in ?? ()
> (gdb) c
[...]
> Sending packet: $vCont;c:p1.1#e2...Ack
Here, we've switched to thread 2, but the packet says to resume thread
1.
This turned out to be a bug in ravenscar_thread_target::resume, which
did not properly handle the case of a "process" resume. In
particular, the resume method would be passed a ptid of (1, 0, 0) --
but then rewrite this to its saved ptid.
This patch fixes the problem by recognizing this case in the resume
method.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target::resume): Handle
"is_pid" case.
This documents some recent Ravenscar changes, and further documents
the known limitation where stepping through the runtime initialization
code does not work properly.
gdb/doc/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* gdb.texinfo (Ravenscar Profile): Add examples.
Document runtime initialization limitation.
A gdb crash showed that the xfer_partial target method was not wrapped
for Ravenscar. This caused remote.c to call
remote::set_general_thread with a Ravenscar "fake" ptid, which showed
up later as an event ptid.
I went through all the target methods and looked to see which ones
could call set_general_thread or set_continue_thread (but not
set_general_process, as I think Ravenscar targets aren't
multi-inferior). This patch wraps the two that I found.
xfer_partial requires special treatment, because it can be called
recursively via get_base_thread_from_ravenscar_task. To avoid a
recursive call, this patch changes update_thread_list to record all
tasks in the m_cpu_map, and changes get_thread_base_cpu to prefer this
map. This avoids some memory reads.
It was unclear to me whether enable_btrace really makes sense for
Ravenscar; but at the same time it seemed harmless to add this patch.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (xfer_partial, enable_btrace, add_thread):
New methods.
(ravenscar_thread_target::get_thread_base_cpu): Check m_cpu_map
first.
(ravenscar_thread_target::add_thread): Rename from
ravenscar_add_thread.
(ravenscar_thread_target::update_thread_list): Use a lambda.
(ravenscar_thread_target::xfer_partial): New method.
This changes iterate_over_live_ada_tasks to accept a
gdb::function_view. This is needed by a subsequent patch.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ada-lang.h (ada_task_list_iterator_ftype): Now a
gdb::function_view.
(iterate_over_live_ada_tasks): Change type of argument.
* ada-tasks.c (iterate_over_live_ada_tasks): Change type
of argument.
Current a Ravenscar thread is given the same sort of name as a "CPU"
thread; they can only be distinguished by looking at the output of
"info thread".
This patch changes ravenscar-thread.c to distinguish these threads,
like:
(gdb) continue
Continuing.
[New Ravenscar Thread 0x2b910]
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target) <extra_thread_info>:
Remove.
(ravenscar_thread_target::extra_thread_info): Remove.
(ravenscar_thread_target::pid_to_str): Mention Ravenscar in result;
defer to target beneath for non-Ravenscar threads.
Currently, the ravenscar runtime can mark an Ada task as the current
task, before adding it to the list of tasks that can be read by gdb.
In this scenario, gdb can sometimes crash in
ravenscar_get_thread_base_cpu with:
../../src/gdb/ravenscar-thread.c:167: internal-error: int ravenscar_get_thread_base_cpu(ptid_t): Assertion `task_info != NULL' failed.
However, as ravenscar_get_thread_base_cpu is only called to find the
base CPU, we can simply record this when registering the thread, and
look this up later.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target) <get_base_cpu,
get_base_thread_from_ravenscar_task>: Now methods.
<m_cpu_map>: New member.
(ravenscar_thread_target::get_thread_base_cpu): Rename from
ravenscar_get_thread_base_cpu. Check m_cpu_map.
(ravenscar_thread_target::task_is_currently_active): Update.
(ravenscar_thread_target::get_base_thread_from_ravenscar_task):
Now a method.
(ravenscar_thread_target::add_active_thread): Put initial thread
into the m_cpu_map.
ravenscar_thread_target::wait should return the event ptid from the
wrapped "wait" call in the situation where returning the Ravenscar
thread ptid is not appropriate. This probably does not really make a
difference in practice, but it seemed like a reasonable cleanup.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target::wait): Return
event_ptid.
An earlier patch caused a Ravenscar regression in
ravenscar_thread_target::wait. In particular, add_active_thread can
return NULL when the runtime is not initialized.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target::wait): Check
runtime_initialized.
Currently ravenscar-thread.c calls add_active_thread before pushing
the ravenscar target. This yields an initial thread announcement of
"[Thread 0]". Calling add_active_thread after pushing the target
fixes this.
gdb/ChangeLog
2020-08-07 Tom Tromey <tromey@adacore.com>
* ravenscar-thread.c (ravenscar_thread_target): Don't call
add_active_thread.
(ravenscar_thread_target::add_active_thread): Now public.
(ravenscar_inferior_created): Call add_active_thread after pushing
the target.
One regcache object is created for each stopped thread and is stored in
the regcache::regcaches linked list. Looking up a regcache for a given
thread is therefore in O(number of threads). Stopping all threads then
becomes O((number of threads) ^ 2). Same goes for resuming a thread
(need to delete the regcache of a given ptid) and resuming all threads.
It becomes noticeable when debugging thousands of threads, which is
typical with GPU targets. This patch replaces the linked list with some
maps to reduce that complexity.
The first design was using an std::unordered_map with (target, ptid,
arch) as the key, because that's how lookups are done (in
get_thread_arch_aspace_regcache). However, the registers_changed_ptid
function, also somewhat on the hot path (it is used when resuming
threads), needs to delete all regcaches associated to a given (target,
ptid) tuple. If the key of the map is (target, ptid, arch), we have to
walk all items of the map, not good.
The second design was therefore using an std::unordered_multimap with
(target, ptid) as the key. One key could be associated to multiple
regcaches, all with different gdbarches. When looking up, we would have
to walk all these regcaches. This would be ok, because there will
usually be actually one matching regcache. In the exceptional
multi-arch thread cases, there will be maybe two. However, in
registers_changed_ptid, we sometimes need to remove all regcaches
matching a given target. We would then have to talk all items of the
map again, not good.
The design as implemented in this patch therefore uses two levels of
map. One std::unordered_map uses the target as the key. The value type
is an std::unordered_multimap that itself uses the ptid as the key. The
values of the multimap are the regcaches themselves. Again, we expect
to have one or very few regcaches per (target, ptid).
So, in summary:
* The lookups (in get_thread_arch_aspace_regcache), become faster when
the number of threads grows, compared to the linked list. With a
small number of threads, it will probably be a bit slower to do map
lookups than to walk a few linked list nodes, but I don't think it
will be noticeable in practice.
* The function registers_changed_ptid deletes all regcaches related to a
given (target, ptid). It must now handle the different cases separately:
- NULL target and minus_one_ptid: we delete all the entries
- NULL target and non-minus_one_ptid: invalid (checked by assert)
- non-NULL target and non-minus_one_ptid: we delete all the entries
associated to that tuple
- a non-NULL target and minus_one_ptid: we delete all the entries
associated to that target
* The function regcache_thread_ptid_changed is called when a thread
changes ptid. It is implemented efficiently using the map, although
that's not very important: it is not called often, mostly when
creating an inferior, on some specific platforms.
This patch is a tiny bit from ROCm GDB [1] we would like to merge
upstream. Laurent Morichetti gave be these performance numbers:
The benchmark used is:
time ./gdb --data-directory=data-directory /extra/lmoriche/hip/samples/0_Intro/bit_extract/bit_extract -ex "set pagination off" -ex "set breakpoint pending on" -ex "b bit_extract_kernel if \$_thread == 5" -ex run -ex c -batch
It measures the time it takes to continue from a conditional breakpoint with
2048 threads at that breakpoint, one of them reporting the breakpoint.
baseline:
real 0m10.227s
real 0m10.177s
real 0m10.362s
with patch:
real 0m8.356s
real 0m8.424s
real 0m8.494s
[1] https://github.com/ROCm-Developer-Tools/ROCgdb
gdb/ChangeLog:
* regcache.c (ptid_regcache_map): New type.
(target_ptid_regcache_map): New type.
(regcaches): Change type to target_ptid_regcache_map.
(get_thread_arch_aspace_regcache): Update to regcaches' new
type.
(regcache_thread_ptid_changed): Likewise.
(registers_changed_ptid): Likewise.
(regcaches_size): Likewise.
(regcaches_test): Update.
(regcache_thread_ptid_changed): Update.
* regcache.h (regcache_up): New type.
* gdbsupport/ptid.h (hash_ptid): New struct.
Change-Id: Iabb0a1111707936ca111ddb13f3b09efa83d3402
I noticed what I think is a potential bug. I did not observe it nor was
I able to reproduce it using actual debugging. It's quite unlikely,
because it involves multi-target and ptid clashes. I added selftests
that demonstrate it though.
The thread_ptid_changed observer says that thread with OLD_PTID now has
NEW_PTID. Now, if for some reason we happen to have two targets
defining a thread with OLD_PTID, the observers don't know which thread
this is about.
regcache::regcache_thread_ptid_changed changes all regcaches with
OLD_PTID. If there is a regcache for a thread with ptid OLD_PTID, but
that belongs to a different target, this regcache will be erroneously
changed.
Similarly, infrun_thread_ptid_changed updates inferior_ptid if
inferior_ptid matches OLD_PTID. But if inferior_ptid currently refers
not to the thread is being changed, but to a thread with the same ptid
belonging to a different target, then inferior_ptid will erroneously be
changed.
This patch adds a `process_stratum_target *` parameter to the
`thread_ptid_changed` observable and makes the two observers use it.
Tests for both are added, which would fail if the corresponding fix
wasn't done.
gdb/ChangeLog:
* observable.h (thread_ptid_changed): Add parameter
`process_stratum_target *`.
* infrun.c (infrun_thread_ptid_changed): Add parameter
`process_stratum_target *` and use it.
(selftests): New namespace.
(infrun_thread_ptid_changed): New function.
(_initialize_infrun): Register selftest.
* regcache.c (regcache_thread_ptid_changed): Add parameter
`process_stratum_target *` and use it.
(regcache_thread_ptid_changed): New function.
(_initialize_regcache): Register selftest.
* thread.c (thread_change_ptid): Pass target to
thread_ptid_changed observable.
Change-Id: I0599e61224b6d154a7b55088a894cb88298c3c71
The DWARF v5 Spec describes a (slightly) new format for V5 .dwp files.
This patch updates GDB to allow it to read/process .dwp files in the
new DWARF v5 format, while continuing to be able to read/process .dwp files
in the older V1 & V2 formats (older, pre-standard formats).
The two major differences between the V2 and the V5 format are:
- The inclusion of DWARF-v5-specific sections:
.debug_loclists.dwo
.debug_rnglists.dwo
- The .dwp section identifier encodings have changed. The table below
shows the old & new encodings. Notice the re-purposing of 5, 7 & 8
in particular.
Val DW4 section DW4 section id DW5 section DW5 section id
--- ----------------- -------------- ----------------- --------------
1 .debug_info.dwo DW_SECT_INFO .debug_info.dwo DW_SECT_INFO
2 .debug_types.dwo DW_SECT_TYPES -- reserved
3 .debug_abbrev.dwo DW_SECT_ABBREV .debug_abbrev.dwo DW_SECT_ABBREV
4 .debug_line.dwo DW_SECT_LINE .debug_line.dwo DW_SECT_LINE
5 .debug_loc.dwo DW_SECT_LOC .debug_loclists.dwo DW_SECT_LOCLISTS
6 .debug_str_offsets.dwo .debug_str_offsets.dwo
DW_SECT_STR_OFFSETS DW_SECT_STR_OFFSETS
7 .debug_macinfo.dwo DW_SECT_MACINFO .debug_macro.dwo DW_SECT_MACRO
8 .debug_macro.dwo DW_SECT_MACRO .debug_rnglists.dwo DW_SECT_RNGLISTS
