I sent a patch in 2013 for this (incorrectly named =thread-created):
https://cygwin.com/ml/gdb-patches/2013-06/msg00129.html
Tom Tromey was ok with the change, but suggested to add a test as well.
Then I forgot about this patch until today. So here it is again, with the
corresponding test.
The problem is that the =thread-exited event does not appear when detaching
from a local process. It does appear with remote though. It's not a really
big deal, but I'd like it to be consistent.
Tested with local and remote Linux on my Ubuntu 14.04.
gdb/ChangeLog:
PR gdb/15564
* inferior.c (detach_inferior): Call exit_inferior_1 with silent = 0.
gdb/testsuite/ChangeLog:
PR gdb/15564
* gdb.mi/mi-detach.exp: New file.
When --build-id=tree is selected, gold would schedule a set of
tasks to run to compute md5 hashes in parallel on chunks of the
file. The scheduling was done before the
Write_after_input_sections_task ran, so if we are compressing
debug sections, the output file will change size and be remapped
to a new address, sometimes causing the build id computation to
crash, but even when it doesn't crash, it wouldn't include the
debug information in the hash computation.
This patch delays the scheduling of the md5 tasks until after
Write_after_input_sections_task.
gold/
PR gold/17819
* gold.cc (queue_final_tasks): When --build-id=tree, queue a
separate task to schedule the build id computation.
* layout.cc (Hash_task::Hash_task): Remove build_id_blocker,
add Output_file and offset.
(Hash_task::run): Get and release the input views.
(Hash_task::is_runnable): Always return NULL (always runnable).
(Layout::queue_build_id_tasks): Remove.
(Layout::write_build_id): Add array_of_hashes and size_of_hashes
parameters; use them instead of class members.
(Build_id_task_runner::run): New function.
(Close_task_runner::run): Pass array_of_hashes and size_of_hashes
to write_build_id.
* layout.h (Layout::queue_build_id_tasks): Remove.
(Layout::write_build_id): Add array_of_hashes and size_of_hashes
parameters.
(Layout::array_of_hashes_): Remove.
(Layout::size_of_array_of_hashes_): Remove.
(Layout::input_view_): Remove.
(Build_id_task_runner): New class.
(Close_task_runner::Close_task_runner): Add array_of_hashes and
size_of_hashes parameters.
(Close_task_runner::array_of_hashes_): New data member.
(Close_task_runner::size_of_hashes_): New data member.
* testsuite/Makefile.am
(flagstest_compress_debug_sections_and_build_id_tree): New test.
* testsuite/Makefile.in: Regenerate.
The ARMv8.1 architecture introduced the Privileged Access Never extension. This
adds a processor state field PSTATE.PAN which can be accessed using the MRS/MSR
instructions.
This patch adds support for the PAN architecture feature and processor state
field to libopcode.
include/opcode
2015-06-01 Matthew Wahab <matthew.wahab@arm.com>
* aarch64.h (AARCH64_FEATURE_PAN): New.
(aarch64_sys_reg_supported_p): Declare.
(aarch64_pstatefield_supported_p): Declare.
opcodes/
2015-06-01 Matthew Wahab <matthew.wahab@arm.com>
* aarch64-opc.c (F_ARCHEXT): New.
(aarch64_sys_regs): Add "pan".
(aarch64_sys_reg_supported_p): New.
(aarch64_pstatefields): Add "pan".
(aarch64_pstatefield_supported_p): New.
Initially there is some chain (let's say the longest one
but that doe snot matter). Consequently its elements from the middle are
being removed and there remains only some few unambiguous top and bottom ones.
The original idea why the comparison should be sharp ("<") was that if there
are multiple chains like (0xaddr show jmp instruction address):
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x200) -> c(0x300) -> d(0x400)
then - such situation cannot exist - if two jmp instructions in "a" have the
same address they must also jump to the same address (*).
(*) jump to a computed address would be never considered for the DWARF
tail-call records.
So there could be:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x270) -> c(0x300) -> d(0x400)
But then "a" frame itself is ambiguous and it must not be displayed.
I did not realize that there can be self-tail-call:
main(0x100) -> a(0x200) -> d(0x400)
main(0x100) -> a(0x280) -> a(0x200) -> d(0x400)
which intersects to:
main(0x100) -> <???>? -> a(0x200) -> d(0x400)
And so if the first chain was chosen the
main(0x100) -> a(0x200) -> d(0x400)
then the final intersection has callers+callees==length.
> for example, if CALLERS is 3 and
> CALLEES is 2, what does the chain look like?
main(0x100) -> x(0x150) -> y(0x200) -> <???>? -> a(0x200) -> d(0x400)
And if LENGTH is 7 then:
call_site[0] = main(0x100)
call_site[1] = x(0x150)
call_site[2] = y(0x200)
call_site[3] = garbage
call_site[4] = garbage
call_site[5] = a(0x200)
call_site[6] = d(0x400)
gdb/ChangeLog
2015-06-01 Andreas Schwab <schwab@linux-m68k.org>
Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* dwarf2-frame-tailcall.c (pretended_chain_levels): Correct
assertion.
* dwarf2loc.c (chain_candidate): Likewise.
gdb/testsuite/ChangeLog
2015-06-01 Jan Kratochvil <jan.kratochvil@redhat.com>
PR symtab/18392
* gdb.arch/amd64-tailcall-self.S: New file.
* gdb.arch/amd64-tailcall-self.c: New file.
* gdb.arch/amd64-tailcall-self.exp: New file.
This patch is to use PTRACE_{G,S}ETREGSET to fetch and store VFP
registers if kernel supports.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_vfp_regs): Use PTRACE_GETREGSET.
(store_vfp_regs): Use PTRACE_SETREGSET.
If kernel supports PTRACE_GETREGSET, GDB uses PTRACE_{G,S}ETREGSET
to fetch and store FP registers.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_fpregister): Use PTRACE_GETREGSET.
(fetch_fpregs): Likewise.
* arm-linux-nat.c (store_fpregister): Use PTRACE_SETREGSET.
(store_fpregs): Likewise.
If kernel supports PTRACE_GETREGSET, GDB uses PTRACE_{G,S}ETREGSET
to fetch and store GP registers.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (fetch_register): Use PTRACE_GETREGSET.
(fetch_regs): Likewise.
(store_regs): Use PTRACE_SETREGSET.
(store_register): Likewise.
I'll let arm-linux-nat.c to use PTRACE_GETREGSET if kernel supports,
so this patch is to move have_ptrace_getregset from x86-linux-nat.c
to linux-nat.c.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* x86-linux-nat.c (have_ptrace_getregset): Move it to ...
* linux-nat.c: ... here.
* x86-linux-nat.h (have_ptrace_getregset): Move the declaration
to ...
* linux-nat.h: ... here.
Macros PTRACE_GETREGSET and PTRACE_SETREGSET are defined locally in
some places in GDB and GDBserver. This patch is to move them to
nat/linux-ptrace.h to avoid duplication.
gdb:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* amd64-linux-nat.c: Include "nat/linux-ptrace.h".
* i386-linux-nat.c: Likewise.
* nat/linux-ptrace.h (PTRACE_GETREGSET, PTRACE_SETREGSET): Define.
* s390-linux-nat.c: Include "nat/linux-ptrace.h".
(PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
* x86-linux-nat.c: Include "nat/linux-ptrace.h".
* x86-linux-nat.h (PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
gdb/gdbserver:
2015-06-01 Yao Qi <yao.qi@linaro.org>
* linux-s390-low.c (PTRACE_GETREGSET, PTRACE_SETREGSET): Remove.
* linux-x86-low.c: Likewise.
BFD_RELOC_AARCH64_TLSLE_ADD_LO12 is used to generate simplest
one-instruction addressing for TLS LE model when tls size is smaller
4K. Linker need to make sure there is no TLS offset overflow.
2015-06-01 Jiong Wang <jiong.wang@arm.com>
bfd/
* elfnn-aarch64.c (elfNN_aarch64_howto_table): Set overflow type to
complain_overflow_unsigned for BFD_RELOC_AARCH64_TLSLE_ADD_LO12.
* elfxx-aarch64.c (_bfd_aarch64_elf_resolve_relocation): Don't use
PGOFF for BFD_RELOC_AARCH64_TLSLE_ADD_LO12, that will mask off all
potential high overflowed bits.
ld/testsuite/
* ld-aarch64/tprel_add_lo12_overflow.s: New testcase.
* ld-aarch64/tprel_add_lo12_overflow.d: Nex expectation file.
* ld-aarch64/aarch64-elf.exp: Run new testcase.
As pointed out before, the documentation mandates the rounding mode to
follow the GPR, so disassembler should produce output accordingly.
gas/testsuite/
2015-06-01 Jan Beulich <jbeulich@suse.com>
* gas/i386/avx512f.s: Adjust operand order for Intel syntax
vcvt{,u}si2ss.
* gas/i386/x86-64-avx512f.s: Adjust operand order for Intel
syntax vcvt{,u}si2s{d,s}.
opcodes/
2015-06-01 Jan Beulich <jbeulich@suse.com>
* i386-dis.c (print_insn): Swap rounding mode specifier and
general purpose register in Intel mode.
As pointed out before, the documentation mandates the rounding mode to
follow the GPR, so gas should accept such input. As the brojen code got
released already we sadly will need to continue to also accept the
badly ordered operands.
gas/testsuite/
2015-06-01 Jan Beulich <jbeulich@suse.com>
* gas/i386/avx512f-intel.d: Adjust expectations on operand order.
* gas/i386/evex-lig256-intel.d: Likewise.
* gas/i386/evex-lig512-intel.d: Likewise.
* gas/i386/x86-64-avx512f-intel.d: Likewise.
* gas/i386/x86-64-evex-lig256-intel.d: Likewise.
* gas/i386/x86-64-evex-lig512-intel.d: Likewise.
opcodes/
2015-06-01 Jan Beulich <jbeulich@suse.com>
* i386-opc.tbl: New IntelSyntax entries for vcvt{,u}si2s{d,s}.
* i386-tbl.h: Regenerate.
gdb/
* go32-nat.c (go32_xfer_memory): Fix the return value to be
compatible to what read_child and write_child return. This
unbreaks that DJGPP build of GDB which was broken since v7.7.
Diagnosis of unexpected input (in this case, in an executable file)
should not crash as if it were a bug in GDB.
gdb/
PR gdb/18464
* osabi.c (generic_elf_osabi_sniff_abi_tag_sections): Use warning
rather than internal_error for an unrecognized value.
Currently access to the last pseudo register is aliased to a1. This is
done by little snippets in the beginning of xtensa_pseudo_register_read
and xtensa_pseudo_register_write that used to do such aliasing for FP
register since bdb4c075a2, but then
FP_ALIAS was expanded into gdbarch_num_regs (current_gdbarch) +
gdbarch_num_pseudo_regs (current_gdbarch) (one register past the last
pseudo register) in 304fe2552d, which
then was changed to the last pseudo register in
94a0e87711.
Drop these snippets.
2015-05-29 Max Filippov <jcmvbkbc@gmail.com>
gdb/
* xtensa-tdep.c (xtensa_pseudo_register_read)
(xtensa_pseudo_register_write): Don't alias last pseudo register
to a1.
The native-extended-gdbserver target now supports fork events and
follow fork, but it does not yet support exec events. Some of the
tests in gdb.base/foll-vfork.exp depend on exec events. This patch
disables those tests for remote targets. We can re-enable these
once the exec event support goes in.
gdb/testsuite/
* gdb.base/foll-vfork.exp (main): Disable exec-dependent
tests for remote targets by checking is_target_gdbserver.
This patch fixes some intermittent test failures in
gdb.base/foll-vfork.exp where a vfork child would be (incorrectly)
resumed when handling the vfork event. In this case the result
was a subsequent event reported to the client side as a SIGTRAP
delivered to the as-yet-unknown child thread.
The new thread was resumed (incorrectly) in linux-low.c when
resume_stopped_resumed_lwps was called from
linux_wait_for_event_filtered after the vfork event had been
handled in handle_extended_wait.
Gdbserver/linux-low.c's add_thread function creates threads with
last_resume_kind == resume_continue by default. This field is
used by resume_stopped_resumed_lwps to decide whether to perform
the resume:
static void
resume_stopped_resumed_lwps (struct inferior_list_entry *entry) {
struct thread_info *thread = (struct thread_info *) entry;
struct lwp_info *lp = get_thread_lwp (thread);
if (lp->stopped
&& !lp->status_pending_p
&& thread->last_resume_kind != resume_stop
&& thread->last_status.kind == TARGET_WAITKIND_IGNORE)
{
So the fix is to make sure to set thread->last_resume_kind to
resume_stop. Here we do that for new fork children in
gdbserver/linux-low.c:handle_extended_wait.
In addition, it seemed prudent to initialize lwp_info.status_pending_p
for the new fork child. I also rearranged the initialization code
so that all of the lwp_info initialization was together, rather than
intermixed with thread_info and process_info initialization.
Tested native, native-gdbserver, native-extended-gdbserver on
x86_64 GNU/Linux.
gdb/gdbserver/
* linux-low.c (handle_extended_wait): Initialize
thread_info.last_resume_kind for new fork children.
This patch fixes a couple of failures in gdb.base/foll-vfork.exp for
extended-remote targets. The failures were the result of the
verbose/debug "Detaching..." messages in infrun.c:follow_fork_inferior
not matching what was expected in the extended-remote case.
The path modifies the ptids used in the messages to ensure that they
print "process nnn" instead of (possibly) "Thread nnn.nnn". The
detach is a process-wide operation, so we need to use a process-
style ptid regardless of what type of ptid target_pid_to_str returns.
Tested on x86_64 GNU/Linux, native, remote, extended-remote.
gdb/
* infrun.c (follow_fork_inferior): Ensure the use of
process-style ptids (pid,0,0) in verbose/debug "Detaching"
messages.
This patch is to remove the global variable arm_linux_has_wmmx_registers
in arm-linux-nat.c, and add a new field have_wmmx_registers in
'struct gdbarch_tdep'.
gdb:
2015-05-28 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (arm_linux_has_wmmx_registers): Remove.
(arm_linux_fetch_inferior_registers): Use
tdep->have_wmmx_registers instead of arm_linux_has_wmmx_registers.
(arm_linux_store_inferior_registers): Likewise.
(arm_linux_read_description): Don't set
arm_linux_has_wmmx_registers.
* arm-tdep.c (arm_gdbarch_init): Set
tdep->have_wmmx_registers according target descriptions.
* arm-tdep.h (struct gdbarch_tdep) <have_wmmx_registers>: New
field.
This patch is to remove the global variable arm_linux_vfp_register_count
from arm-linux-nat.c. This global variable is set when native gdb
looks for the right target description according HWCAP. However,
'struct gdbarch_tdep' has already had a field have_vfp_registers, which
is a boolean about whether target has vfp registers or not. This
patch converts this boolean field to a numeric counter to replace
global variable arm_linux_vfp_register_count.
gdb:
2015-05-28 Yao Qi <yao.qi@linaro.org>
* arm-linux-nat.c (arm_linux_vfp_register_count): Remove.
(fetch_vfp_regs): Use vfp_register_count from gdbarch_tdep
instead of arm_linux_vfp_register_count.
(store_vfp_regs): Likewise.
(arm_linux_fetch_inferior_registers): Likewise.
(arm_linux_store_inferior_registers): Likewise.
(arm_linux_read_description): Don't set
arm_linux_vfp_register_count.
* arm-linux-tdep.c (arm_linux_iterate_over_regset_sections):
Adjust.
* arm-tdep.c (arm_gdbarch_init): Add assert on
vfp_register_count.
* arm-tdep.h (struct gdbarch_tdep) <have_vfp_registers>: Rename
field to vfp_register_count. All users updated.
On ARM systems, gdb must determine which style of breakpoint to use
(see the comments at the beginning of gdb/arm-linux-tdep.c). In
arm_gdbarch_init we only attempt to extract the eabi version from the
ELF binary if it is a ELFOSABI_NONE binary. If the binary is
ELFOSABI_GNU instead, we end up defaulting to the old style OABI
syscall breakpoint instruction. On a Linux kernel built without
CONFIG_OABI_COMPAT, this triggers a SIGILL in ld when attempting to
execute any ELFOSABI_GNU program.
(e.g. https://github.com/raspberrypi/linux/issues/766)
gdb/
2015-05-28 Kyle Huey <me@kylehuey.com> (tiny patch)
* gdb/arm-tdep.c (arm_gdbarch_init): Perform arm_abi detection on
ELFOSABI_GNU binaries.
gdb/ChangeLog:
* dwarf2read.c (lnp_state_machine): New typedef.
(lnp_reader_state): New typedef.
(dwarf_record_line_1): Renamed from dwarf_record_line.
All callers updated.
(dwarf_record_line): New function.
(init_lnp_state_machine): New function.
(check_line_address): Replace p_record_line parameter with state.
All callers updated.
(dwarf_decode_lines_1): Call dwarf_record_line, init_lnp_state_machine.
Update to record state in lnp_state_machine.
