aboutsummaryrefslogtreecommitdiff
path: root/gdb/p-valprint.c
diff options
context:
space:
mode:
authorPedro Alves <palves@redhat.com>2016-05-24 14:47:56 +0100
committerPedro Alves <palves@redhat.com>2016-05-24 14:47:56 +0100
commitaa01bd3689d204ce3d657cf7eb17b8343d79a080 (patch)
treee920ffdda9fa46a22248aed87550cdd222407c57 /gdb/p-valprint.c
parent44d3da2338157ad7acfd6facbcfb38ed6ec94fa1 (diff)
downloadgdb-aa01bd3689d204ce3d657cf7eb17b8343d79a080.zip
gdb-aa01bd3689d204ce3d657cf7eb17b8343d79a080.tar.gz
gdb-aa01bd3689d204ce3d657cf7eb17b8343d79a080.tar.bz2
Linux native thread create/exit events support
A following patch (fix for gdb/19828) makes linux-nat.c add threads to GDB's thread list earlier in the "attach" sequence, and that causes a surprising regression on gdb.threads/attach-many-short-lived-threads.exp on my machine. The extra "thread x exited" handling and traffic slows down that test enough that GDB core has trouble keeping up with new threads that are spawned while trying to stop existing ones. I saw the exact same issue with remote/gdbserver a while ago and fixed it in 65706a29bac5 (Remote thread create/exit events) so part of the fix here is the exact same -- add support for thread created events to gdb/linux-nat.c. infrun.c:stop_all_threads enables those events when it tries to stop threads, which ensures that new threads never get a chance to themselves start new threads, thus fixing the race. gdb/ 2016-05-24 Pedro Alves <palves@redhat.com> PR gdb/19828 * linux-nat.c (report_thread_events): New global. (linux_handle_extended_wait): Report TARGET_WAITKIND_THREAD_CREATED if thread event reporting is enabled. (wait_lwp, linux_nat_filter_event): Report all thread exits if thread event reporting is enabled. Remove comment. (filter_exit_event): New function. (linux_nat_wait_1): Use it. (linux_nat_thread_events): New function. (linux_nat_add_target): Install it as target_thread_events method.
Diffstat (limited to 'gdb/p-valprint.c')
0 files changed, 0 insertions, 0 deletions