Rename target_ops.arch_setup to .post_create_inferior. In the Linux
hook, continue calling the low arch setup, then also set ptrace flags.
This corrects the possibility of running without flags, demonstrated by
a new test that would fail to catch a fork before.
gdb/gdbserver/ChangeLog:
2015-12-04 Josh Stone <jistone@redhat.com>
* target.h (struct target_ops) <arch_setup>: Rename to ...
(struct target_ops) <post_create_inferior>: ... this.
(target_arch_setup): Rename to ...
(target_post_create_inferior): ... this, calling post_create_inferior.
* server.c (start_inferior): Update target_arch_setup calls to
target_post_create_inferior.
* linux-low.c (linux_low_ptrace_options): Forward declare.
(linux_arch_setup): Update its comment for general use.
(linux_post_create_inferior): New, run arch_setup and setup ptrace.
(struct linux_target_ops): Use linux_post_create_inferior.
* lynx-low.c (struct lynx_target_ops): Update arch_setup stub comment
to post_create_inferior.
* nto-low.c (struct nto_target_ops): Likewise.
* spu-low.c (struct spu_target_ops): Likewise.
* win32-low.c (struct win32_target_ops): Likewise.
gdb/testsuite/ChangeLog:
2015-12-04 Josh Stone <jistone@redhat.com>
* gdb.base/catch-fork-static.exp: New.
A duplicate include arm/arm.h was introduced, remove it.
Pushed as obvious.
gdb/gdbserver/ChangeLog:
* linux-arm-low.c: Remove duplicate arch/arm.h include.
This patch removes too simple implementations of the breakpoint_reinsert_addr
operation.
The only reason to keep them around was to support thread events when
PTRACE_EVENT_CLONE was not present but this support has been removed in a
previous patch.
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
Also compilation was tested on aarch64, bfin, cris, crisv32,
m32r, mips, nios2, ppc, s390, sparc, tic6x, tile, xtensa.
gdb/gdbserver/ChangeLog:
* linux-arm-low.c (arm_reinsert_addr): Remove function.
(struct linux_target_ops <breakpoint_reinsert_addr>: Set to NULL.
* linux-cris-low.c (cris_reinsert_addr> Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-crisv32-low.c (cris_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-mips-low.c (mips_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-nios2-low.c (nios2_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
* linux-sparc-low.c (sparc_reinsert_addr): Remove function.
(struct linux_target_ops) <breakpoint_reinsert_addr>: Set to NULL.
This patch removes support for thread events if PTRACE_EVENT_CLONE is not
supported in GDBServer.
Before, on systems that did not support PTRACE_EVENT_CLONE, both GDB and
GDBServer coordinated with libthread_db.so to insert breakpoints at magic
locations in libpthread.so, in order to break at thread creation and thread
death.
Simple software single stepping support was implemented to step over these
breakpoints in case there was no hardware single stepping support. However,
these simple software single stepping implementations were not fit for any other
use as discussed in :
https://sourceware.org/ml/gdb-patches/2015-04/msg01110.html
These too simple implementations conflict with ongoing work to make proper
implementations of software single stepping in GDBServer.
The problem is that if some implementations are correct and others are not and
only there for the thread magic breakpoint, we can't enable features based
solely software single step support since some would be broken.
To keep the incorrect implementations and allow the new proper ones at the same
time we would need to implement fallback code and it quickly becomes ugly and
confusing with multiple checks for legacy software single step or proper
software single step.
However, PTRACE_EVENT_CLONE was first introduced in Linux 2.5.46,
released in November 2002.
So I think it's reasonable to just remove support for kernels that don't support
PTRACE_EVENT_CLONE, and sidestep the libthread_db breakpoints issues entirely.
This thread on the mailling list discusses the issue :
https://sourceware.org/ml/gdb/2015-10/msg00078.html
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_look_up_symbols): Don't call
linux_supports_traceclone.
* linux-low.h (thread_db_init): Remove use_events argument.
* thread-db.c (thread_db_use_event): Remove global variable.
(struct thread_db) <td_thr_event_enable_p>: Remove field.
(struct thread_db) <td_create_bp>: Remove field.
(thread_db_create_event): Remove function.
(thread_db_enable_reporting): Likewise.
(find_one_thread): Don't check for thread_db_use_events.
(attach_thread): Likewise.
(thread_db_load_search): Remove td_thr_event_enable_p initialization.
(try_thread_db_load_1): Don't check for thread_db_use_events.
(thread_db_init): Remove use_events argument and thread events
handling.
(remove_thread_event_breakpoints): Remove function.
(thread_db_detach): Remove call to remove_thred_event_breakpoints.
Before this patch there was only one call: can_hardware_single_step. Its
implementation was a check on breakpoint_reinsert_addr if NULL it assumed
that the target could hardware single step.
This patch prepares for the case where this is not true anymore.
In order to improve software single stepping in GDBServer the
breakpoint_reinsert_addr operation of targets that had a very simple
software implementation used only for stepping over thread creation events
will be removed.
This will create a case where a target does not support hardware single
step and has the operation breakpoint_reinsert_addr set to NULL, thus
can_hardware_single_step needs to be implemented another way.
A new target operation supports_hardware_single_step is introduced and is
to return true if the target does support such a feature, support for the
feature is manually hardcoded.
Note that the hardware single step support was enabled as per the current
behavior, I did not check if tile for example really has ptrace singlestep
support but since the current implementation assumed it had, I kept it
that way.
No regressions on Ubuntu 14.04 on ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
Compilation tested on: aarch64,arm,bfind,crisv32,m32r,ppc,s390,tic6x,tile,
xtensa.
Not tested : sh.
gdb/gdbserver/ChangeLog:
* linux-aarch64-low.c (aarch64_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-arm-low.c (arm_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-bfin-low.c (bfin_supports_hardware_single_step): New function.
(struct linux_target_ops) <bfin_supports_hardware_single_step>:
Initialize.
* linux-crisv32-low.c (cris_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-low.c (can_hardware_single_step): Use
supports_hardware_single_step.
(can_software_single_step): New function.
(start_step_over): Call can_software_single_step.
(linux_supports_hardware_single_step): New function.
(struct target_ops) <supports_software_single_step>: Initialize.
* linux-low.h (struct linux_target_ops)
<supports_hardware_single_step>: Initialize.
* linux-m32r-low.c (m32r_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-ppc-low.c (ppc_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step> Initialize.
* linux-s390-low.c (s390_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-sh-low.c (sh_supports_hardware_single_step): New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-tic6x-low.c (tic6x_supports_hardware_single_step): New function.
(struct linux_target_ops) <tic6x_supports_hardware_single_step>:
Initialize.
* linux-tile-low.c (tile_supports_hardware_single_step): New function.
(struct linux_target_ops) <tile_supports_hardware_single_step>:
Initialize.
* linux-x86-low.c (x86_supports_hardware_single_step) New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* linux-xtensa-low.c (xtensa_supports_hardware_single_step):
New function.
(struct linux_target_ops) <supports_hardware_single_step>: Initialize.
* target.h (struct target_ops): <supports_software_single_step>:
New field.
(target_supports_software_single_step): New macro.
Without this patch, when doing a software single step, with for example
a conditional breakpoint, gdbserver would wrongly avance the pc of
breakpoint_len and skips an instruction.
This is due to gdbserver assuming that it's hardware single stepping.
When it resumes from the breakpoint address it expects the trap to be
caused by ptrace and if it's rather caused by a software breakpoint
it assumes this is a permanent breakpoint and that it needs to skip
over it.
However when software single stepping, this breakpoint is legitimate as
it's the reinsert breakpoint gdbserver has put in place to break at
the next instruction. Thus gdbserver wrongly advances the pc and skips
an instruction.
This patch fixes this behavior so that gdbserver checks if it is a
reinsert breakpoint from software single stepping. If it is it won't
advance the pc. And if there's no reinsert breakpoint there we assume
then that it's a permanent breakpoint and advance the pc.
Here's a commented log of what would happen before and after the fix on
gdbserver :
/* Here there is a conditional breakpoint at 0x10428 that needs to be
stepped over. */
Need step over [LWP 11204]? yes, found breakpoint at 0x10428
...
/* e7f001f0 is a breakpoint instruction on arm
Here gdbserver writes the software breakpoint we would like to hit
*/
Writing e7f001f0 to 0x0001042c in process 11204
...
Resuming lwp 11220 (continue, signal 0, stop not expected)
pending reinsert at 0x10428
stop pc is 00010428
continue from pc 0x10428
...
/* Here gdbserver hit the software breakpoint that was in place
for the step over */
stop pc is 0001042c
pc is 0x1042c
step-over for LWP 11220.11220 executed software breakpoint
Finished step over.
Could not find fast tracepoint jump at 0x10428 in list (reinserting).
/* Here gdbserver writes back the original instruction */
Writing e50b3008 to 0x0001042c in process 11220
Step-over finished.
Need step over [LWP 11220]? No
/* Here because gdbserver assumes this is a permenant breakpoint it advances
the pc of breakpoint_len, in this case 4 bytes, so we have just skipped
the instruction that was written back here :
Writing e50b3008 to 0x0001042c in process 11220
*/
stop pc is 00010430
pc is 0x10430
Need step over [LWP 11220]? No, no breakpoint found at 0x10430
Proceeding, no step-over needed
proceed_one_lwp: lwp 11220
stop pc is 00010430
This patch fixes this situation and we get the right behavior :
Writing e50b3008 to 0x0001042c in process 11245
Hit a gdbserver breakpoint.
Hit a gdbserver breakpoint.
Step-over finished.
proceeding all threads.
Need step over [LWP 11245]? No
stop pc is 0001042c
pc is 0x1042c
Need step over [LWP 11245]? No, no breakpoint found at 0x1042c
Proceeding, no step-over needed
proceed_one_lwp: lwp 11245
stop pc is 0001042c
pc is 0x1042c
Resuming lwp 11245 (continue, signal 0, stop not expected)
stop pc is 0001042c
continue from pc 0x1042c
It also works if the value at 0x0001042c is a permanent breakpoint.
If so gdbserver will finish the step over, remove the reinserted breakpoint,
resume at that location and on the next SIGTRAP gdbserver will trigger
the advance PC condition as reinsert_breakpoint_inserted_here will be false.
I also tested this against bp-permanent.exp on arm (with a work in progress
software single step patchset) without any regressions.
It's also tested against x86 bp-permanent.exp without any regression.
So both software and hardware single step are tested.
No regressions on Ubuntu 14.04 on ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_wait_1): Fix pc advance condition.
* mem-break.c (reinsert_breakpoint_inserted_here): New function.
* mem-break.h (reinsert_breakpoint_inserted_here): New declaration.
When manually stepping over a permanent breakpoint on ARM we need to fetch the
right breakpoint size based on the current instruction set used.
Since this is not encoded in the stop_pc, the instruction mode needs to be
fetched from the CPSR register.
This is done by introducing a new target operation called :
breakpoint_kind_from_current_state.
For other targets that do not need this, breakpoint_kind_from_pc is used.
No regressions, tested on ubuntu 14.04 ARMv7 and x86.
With gdbserver-{native,extended} / { -marm -mthumb }
gdb/gdbserver/ChangeLog:
* linux-arm-low.c (arm_is_thumb_mode): New function.
(arm_breakpoint_at): Use arm_is_thumb_mode.
(arm_breakpoint_kind_from_current_state): New function.
(struct linux_target_ops) <breakpoint_kind_from_current_state>:
Initialize.
* linux-low.c (linux_wait_1): Call breakpoint_kind_from_current_state.
(linux_breakpoint_kind_from_current_state): New function.
(struct target_ops <breakpoint_kind_from_current_state>: Initialize.
* linux-low.h (struct linux_target_ops)
<breakpoint_kind_from_current_state>: New field.
* target.h (struct target_ops): Likewise.
(target_breakpoint_kind_from_current_state): New macro.
When testing with "target remote" with "maint set target-non-stop on",
we regressions like this:
Running /home/pedro/gdb/mygit/build/../src/gdb/testsuite/gdb.threads/continue-pending-after-query.exp ...
FAIL: gdb.threads/continue-pending-after-query.exp: iter 4: continue until exit
FAIL: gdb.threads/continue-pending-after-query.exp: iter 6: continue until exit
FAIL: gdb.threads/continue-pending-after-query.exp: iter 10: continue until exit
=== gdb Summary ===
# of expected passes 28
# of unexpected failures 3
where gdb.log shows:
continue
Continuing.
Remote communication error. Target disconnected.: Connection reset by peer.
(gdb) FAIL: gdb.threads/continue-pending-after-query.exp: iter 4: continue until exit
Enabling gdb + gdbserver debug logs we see:
gdbserver: <<<< exiting linux_wait_1
gdbserver: handling possible serial event
gdbserver: Writing resume reply for LWP 11089.11089:0
gdbserver: handling possible serial event
gdbserver: GDBserver exiting
GDB: Packet received: OK
GDB: infrun: prepare_to_wait
GDB: Sending packet: $vStopped#55...Packet received: W0;process:2b51
GDB: Sending packet: $vStopped#55...Packet received: OK
GDB: infrun: target_wait (-1.0.0, status) =
GDB: infrun: -1.0.0 [Thread 0],
GDB: infrun: status->kind = no-resumed
GDB: Sending packet: $Hgp2b51.2b51#41...Remote connection closed
(gdb) FAIL: gdb.threads/continue-pending-after-query.exp: iter 1: continue until exit
Notice the "Packet received: W0;process:2b51" followed by
vStopped->OK.
That means the process exit notification was successfully sent to GDB
and GDB fetched it. That makes gdbserver exit, in
server.c:process_serial_event:
if (!extended_protocol && have_ran && !target_running ())
{
/* In non-stop, defer exiting until GDB had a chance to query
the whole vStopped list (until it gets an OK). */
if (QUEUE_is_empty (notif_event_p, notif_stop.queue))
{
/* Be transparent when GDB is connected through stdio -- no
need to spam GDB's console. */
if (!remote_connection_is_stdio ())
fprintf (stderr, "GDBserver exiting\n");
remote_close ();
exit (0);
}
}
However, GDB is still busy processing an earlier "no-resumed" event,
and sends a "Hg" packet, which errors out with "Remote connection
closed". IOW, it's not enough to wait for GDB to query the whole
vStopped list, gdbserver needs to wait until the exit event is really
processed.
The fix is to make gdbserver not disconnect until gdb does.
Tested on x86_64 Fedora, native gdbserver, remote + extended-remote +
with and without "maint set target-non-stop on".
gdb/gdbserver/ChangeLog:
2015-10-14 Pedro Alves <palves@redhat.com>
* remote-utils.c (readchar): Don't print "Got EOF" unless
debugging gdbserver.
* server.c (captured_main): Exit gdbserver if gdb disconnects when
in "target remote" mode and there are no processes left to debug.
(process_serial_event): Remove 'have_ran' static local and remove
logic that exits gdbserver in "target remote" mode.
Running killed-outside.exp in with "maint set target-non-stop on"
hangs currently. This test has the inferior process die with a
SIGKILL while stopped. gdbserver gets a SIGCHLD and reacts by
retrieveing the SIGKILL events out of waitpid. But because the
process is not resumed from GDB's perspective, the event is left
pending. When GDB resumes the process afterwards, the process is not
really resumed because it already has the event pending. But nothing
wakes up the event loop to consume the event.
Handle this in the same way nat/linux-nat.c:linux_nat_resume handles
this.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_resume): Wake up the event loop before
returning.
Say GDB wants to access the inferior process's memory. The current
remote general thread is 3, but GDB's switched to thread 2. Because
both threads are of the same process, GDB skips making the remote
thread be thread 2 as well (sending an Hg packet) before accessing
memory (remote.c:set_general_process). However, if thread 3 has
exited meanwhile, thread 3 no longer exists on the server and
gdbserver points current_thread to NULL. The result is the memory
access fails, even through the process still exists.
Fix this by making prepare_to_access memory select the thread to
access memory through.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* mem-break.c (check_gdb_bp_preconditions): Remove current_thread
check.
(set_gdb_breakpoint): If prepare_to_access_memory fails, set *ERR
to -1.
* target.c (struct thread_search): New structure.
(thread_search_callback): New function.
(prev_general_thread): New global.
(prepare_to_access_memory, done_accessing_memory): New functions.
* target.h (prepare_to_access_memory, done_accessing_memory):
Replace macros with function declarations.
Testing with "maint set target-non-stop on" causes regressions in
tests that rely on TARGET_WAITKIND_NO_RESUMED, which isn't modelled on
the RSP. In real all-stop, gdbserver detects the situation and
reporst error to GDB, and so the tests (e.g.,
gdb.threads/no-unwaited-for-left.exp) at fail quickly. But with
"maint set target-non-stop on", GDB instead hangs forever waiting for
a stop reply that never comes, and so the tests take longer to time
out.
This adds a new "N" stop reply packet that maps 1-1 to
TARGET_WAITKIND_NO_RESUMED.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* NEWS (New remote packets): Mention the N stop reply.
* remote.c (remote_protocol_features): Add "no-resumed" entry.
(remote_query_supported): Report no-resumed+ support.
(remote_parse_stop_reply): Handle 'N'.
(process_stop_reply): Handle TARGET_WAITKIND_NO_RESUMED.
(remote_wait_as): Handle 'N' / TARGET_WAITKIND_NO_RESUMED.
(_initialize_remote): Register "set/show remote
no-resumed-stop-reply" commands.
gdb/doc/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* gdb.texinfo (Stop Reply Packets): Document the N stop reply.
(Remote Configuration): Add the "set/show remote
no-resumed-stop-reply" to the available settings table.
(General Query Packets): Document the "no-resumed" qSupported
feature.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
PR 14618
* linux-low.c (linux_wait_1): If the last resumed thread is gone,
report TARGET_WAITKIND_NO_RESUMED.
* remote-utils.c (prepare_resume_reply): Handle
TARGET_WAITKIND_NO_RESUMED.
* server.c (report_no_resumed): New global.
(handle_query) <qSupported>: Handle "no-resumed+". Report
"no-resumed+" support.
(resume): When the target reports TARGET_WAITKIND_NO_RESUMED, only
return error if the client doesn't support no-resumed events.
(push_stop_notification): New function.
(handle_target_event): Use it. Report TARGET_WAITKIND_NO_RESUMED
events if the client supports them.
gdb/testsuite/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.threads/no-unwaited-for-left.exp: Remove setup_kfail calls.
killed-outside.exp regresses with "maint set target-non-stop on". The
logs show:
(gdb) continue
Continuing.
infrun: clear_proceed_status_thread (Thread 9028.9028)
infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT)
infrun: proceed: resuming Thread 9028.9028
Sending packet: $Z0,3615a03966,1#4b... Notification received: Stop:X9;process:2344
Packet received: E01
Sending packet: $Z0,3615a13970,1#47...Packet received: E01
Sending packet: $Z0,3615a14891,1#4a...Packet received: E01
infrun: resume (step=0, signal=GDB_SIGNAL_0), trap_expected=0, current thread [Thread 9028.9028] at 0x4005e4
Sending packet: $vCont;c:p2344.2344#1a...Packet received: E.target not running.
Sending packet: $qXfer:threads:read::0,fff#03...Packet received: l<threads>\n</threads>\n
Sending packet: $vStopped#55...Packet received: OK
Unexpected vCont reply in non-stop mode: E.target not running.
(gdb) remote_async_inferior_event_handler
infrun: target_wait (-1.0.0, status) =
infrun: 9028.0.0 [process 9028],
infrun: status->kind = signalled, signal = GDB_SIGNAL_KILL
infrun: TARGET_WAITKIND_SIGNALLED
Program terminated with signal SIGKILL, Killed.
The program no longer exists.
infrun: stop_waiting
infrun: clear_step_over_info
infrun: stop_all_threads
remote_thread_exit_events(1)
Note the "Unexpected vCont reply" error.
I traced it to a problem in status_pending_p_callback. It resumes an
LWP when it shouldn't.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (thread_still_has_status_pending_p): Don't check
vCont;t here.
(lwp_resumed): New function.
(status_pending_p_callback): Return early if the LWP is not
supposed to be resumed.
When testing with "maint set target-non-stop on", a few
threading-related tests expose an issue that requires new RSP packets.
Say there are 3 threads running, 1-3. If GDB tries to stop thread 1,
2 and 3, and then waits for their stops, but meanwhile say, thread 2
exits, GDB hangs forever waiting for a stop for thread 2 that won't
ever happen.
This patch fixes the issue by adding support for thread exit events to
the protocol. However, we don't want these always enabled, as they're
useless most of the time, and would slow down remote debugging. So I
made it so that GDB can enable/disable them, and then made gdb do that
around the cases that need it, which currently is only
infrun.c:stop_all_threads.
In turn, if we have thread exit events, then the extra "thread x
exited" traffic slows down attach-many-short-lived-threads.exp enough
that gdb has trouble keeping up with new threads that are spawned
while gdb tries to stop existing ones. To fix that I added support
for the counterpart thread created events too. Enabling those when we
try to stop threads ensures that new threads never get a chance to
themselves start new threads, killing the race.
gdb/doc/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Remote Configuration): List "set/show remote
thread-events" command in configuration table.
(Stop Reply Packets): Document "T05 create" stop
reason and 'w' stop reply.
(General Query Packets): Document QThreadEvents packet. Document
QThreadEvents qSupported feature.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (handle_extended_wait): Assert that the LWP's
waitstatus is TARGET_WAITKIND_IGNORE. If GDB wants to hear about
thread create events, leave the new child's status pending.
(linux_low_filter_event): If GDB wants to hear about thread exit
events, leave the LWP marked dead and don't delete it.
(linux_wait_for_event_filtered): Don't check for thread exit.
(filter_exit_event): New function.
(linux_wait_1): Use it, when returning an exit event.
(linux_resume_one_lwp_throw): Assert that the LWP's
waitstatus is TARGET_WAITKIND_IGNORE.
* remote-utils.c (prepare_resume_reply): Handle
TARGET_WAITKIND_THREAD_CREATED and TARGET_WAITKIND_THREAD_EXITED.
* server.c (report_thread_events): New global.
(handle_general_set): Handle QThreadEvents.
(handle_query) <qSupported>: Handle and report QThreadEvents+;
(handle_target_event): Handle TARGET_WAITKIND_THREAD_CREATED and
TARGET_WAITKIND_THREAD_EXITED.
* server.h (report_thread_events): Declare.
gdb/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* NEWS (New commands): Mention "set/show remote thread-events"
commands.
(New remote packets): Mention thread created/exited stop reasons
and QThreadEvents packet.
* infrun.c (disable_thread_events): New function.
(stop_all_threads): Disable/enable thread create/exit events.
Handle TARGET_WAITKIND_THREAD_EXITED.
(handle_inferior_event_1): Handle TARGET_WAITKIND_THREAD_CREATED
and TARGET_WAITKIND_THREAD_EXITED.
* remote.c (remove_child_of_pending_fork): Also remove threads of
threads that have TARGET_WAITKIND_THREAD_EXITED events.
(remote_parse_stop_reply): Handle "create" magic register. Handle
'w' stop reply.
(initialize_remote): Install remote_thread_events as
to_thread_events target hook.
(remote_thread_events): New function.
* target-delegates.c: Regenerate.
* target.c (target_thread_events): New function.
* target.h (struct target_ops) <to_thread_events>: New field.
(target_thread_events): Declare.
* target/waitstatus.c (target_waitstatus_to_string): Handle
TARGET_WAITKIND_THREAD_CREATED and TARGET_WAITKIND_THREAD_EXITED.
* target/waitstatus.h (enum target_waitkind)
<TARGET_WAITKIND_THREAD_CREATED, TARGET_WAITKIND_THREAD_EXITED):
New values.
Running attach-many-short-lived-threads.exp with the extended-remote
board with "maint set target-non-stop on" times out -- the attach
never completes. Enabling infrun debug logs, we see that GDB is stuck
stopping all threads:
infrun: target_wait (-1.0.0, status) =
infrun: 1639.22213.0 [Thread 1639.22213],
infrun: status->kind = stopped, signal = GDB_SIGNAL_0
infrun: Thread 1639.22260 not executing
infrun: Thread 1639.22256 not executing
infrun: Thread 1639.22258 not executing
infrun: Thread 1639.22257 not executing
infrun: Thread 1639.22259 not executing
infrun: Thread 1639.22255 not executing
infrun: Thread 1639.22253 executing, already stopping
infrun: Thread 1639.22251 executing, already stopping
infrun: Thread 1639.22252 executing, already stopping
infrun: Thread 1639.22250 executing, already stopping
infrun: Thread 1639.22254 executing, already stopping
infrun: Thread 1639.22247 executing, already stopping
infrun: Thread 1639.22213 not executing
infrun: Thread 1639.22207 not executing
infrun: Thread 1639.22201 not executing
infrun: Thread 1639.22219 not executing
infrun: Thread 1639.1639 not executing
** HANG HERE **
GDB is waiting for the stop replies of any of those "already stopping"
threads. Take 22253 for example. On the gdbserver logs we see:
...
resume_stop request for LWP 22253
stopping LWP 22253
Sending sigstop to lwp 22253
linux_resume done
...
and:
my_waitpid (-1, 0x40000001)
my_waitpid (-1, 0x80000001): status(3057f), 22253
LWFE: waitpid(-1, ...) returned 22253, ERRNO-OK
LLW: waitpid 22253 received Trace/breakpoint trap (stopped)
pc is 0x3615ef4ce1
HEW: Got clone event from LWP 22253, new child is LWP 22259
but from here on, we never see any other event for LWP 22253. In
particular, we never see the expected SIGSTOP (from "Sending sigstop"
above). The issue is that linux_resume_stopped_resumed_lwps never
re-resumes the 22253 after the clone event.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (resume_stopped_resumed_lwps): Don't check whether
the thread's last_resume_kind was resume_stop.
With "maint set target-non-stop on", the attach tests occasionally
crash gdbserver.
Basically, gdb attaches with vAttach;PID, and then shortly after reads
the xml target description for that process, to figure out the
process' architecture. On the gdbserver side, the target description
is only filled in when the first process/thread in the thread group
reports its initial PTRACE_ATTACH SIGSTOP. So if GDB is fast enough,
it can read the target description _before_ that initial stop, and
then gdbserver dies dereferencing a NULL tdesc pointer.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_attach): In non-stop mode, wait for one stop
before returning.
There's currently no non-stop equivalent of the all-stop ^C (\003)
"packet" that GDB sends when a ctrl-c is pressed while a foreground
command is active. There's vCont;t, but that's defined to cause a
"signal 0" stop.
This fixes many tests that type ^C, when testing with extended-remote
with "maint set target-non-stop on". E.g.:
Continuing.
talk to me baby
PASS: gdb.base/interrupt.exp: process is alive
a
a
PASS: gdb.base/interrupt.exp: child process ate our char
^C
[Thread 22730.22730] #1 stopped.
0x0000003615ee6650 in __read_nocancel () at ../sysdeps/unix/syscall-template.S:81
81 T_PSEUDO (SYSCALL_SYMBOL, SYSCALL_NAME, SYSCALL_NARGS)
(gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C
p func1 ()
gdb/
2015-11-30 Pedro Alves <palves@redhat.com>
* NEWS (New remote packets): Mention vCtrlC.
* remote.c (PACKET_vCtrlC): New enum value.
(async_remote_interrupt): Call target_interrupt instead of
target_stop.
(remote_interrupt_as): Remove 'ptid' parameter.
(remote_interrupt_ns): New function.
(remote_stop): Adjust.
(remote_interrupt): If the target is in non-stop mode, try
interrupting with vCtrlC.
(initialize_remote): Install set remote ctrl-c packet.
gdb/doc/
2015-11-30 Pedro Alves <palves@redhat.com>
* gdb.texinfo (Bootstrapping): Add "interrupting remote targets"
anchor.
(Packets): Document vCtrlC.
gdb/gdbserver/
2015-11-30 Pedro Alves <palves@redhat.com>
* server.c (handle_v_requests): Handle vCtrlC.
This fixes a gdbserver crash when running
gdb.threads/non-ldr-exc-1.exp with "maint set target-non-stop on".
The problem is that qSymbol is called when gdbserver has
current_thread == NULL.
gdb/gdbserver/ChangeLog:
2015-11-30 Pedro Alves <palves@redhat.com>
* gdbthread.h (find_any_thread_of_pid): Declare.
* inferiors.c (thread_of_pid, find_any_thread_of_pid): New
functions.
* server.c (handle_query): If current_thread is NULL, look for
another thread of the selected process.
This patch adds support for thread names in the remote protocol, and
updates gdb/gdbserver to use it. The information is added to the XML
description sent in response to the qXfer:threads:read packet.
gdb/ChangeLog:
* linux-nat.c (linux_nat_thread_name): Replace implementation by call
to linux_proc_tid_get_name.
* nat/linux-procfs.c (linux_proc_tid_get_name): New function,
implementation inspired by linux_nat_thread_name.
* nat/linux-procfs.h (linux_proc_tid_get_name): New declaration.
* remote.c (struct private_thread_info) <name>: New field.
(free_private_thread_info): Free name field.
(remote_thread_name): New function.
(thread_item_t) <name>: New field.
(clear_threads_listing_context): Free name field.
(start_thread): Get name xml attribute.
(thread_attributes): Add "name" attribute.
(remote_update_thread_list): Copy name field.
(init_remote_ops): Assign remote_thread_name callback.
* target.h (target_thread_name): Update comment.
* NEWS: Mention remote thread name support.
gdb/gdbserver/ChangeLog:
* linux-low.c (linux_target_ops): Use linux_proc_tid_get_name.
* server.c (handle_qxfer_threads_worker): Refactor to include thread
name in reply.
* target.h (struct target_ops) <thread_name>: New field.
(target_thread_name): New macro.
gdb/doc/ChangeLog:
* gdb.texinfo (Thread List Format): Mention thread names.
This crash is observable by debugging a threaded program on LynxOS.
On the GDB side, this is what we would see:
% gdb q
(gdb) target remote machine:4444
(gdb) break q.adb:6
(gdb) cont
[gdb hits breakpoint]
(gdb) cont
Remote connection closed <<<--- expected: [Inferior 1 (Remote target) exited normally]
On the gdbserver side, which was launched as usual:
% gdbserver --once :4444 q
Segmentation fault (core dumped)
Ooops!
The problem happens while GDB is trying to handle the thread termination
event of the thread that hit the breakpoint. It started happening after
the following change was made:
commit 96e7a1eb6d
Date: Fri Oct 16 11:08:38 2015 -0400
Subject: gdbserver: Reset current_thread when the thread is removed.
Reset current_thread and make sure 'remove_process' is used
after all associated threads have been removed first.
More precisely:
. GDBserver receives the execution-resume order;
. lynx-low resumes it succesfully, and then relies on lynx_wait_1
to wait for the next event;
. We quickly receive one, which lynx_wait_1 analyzes to be
a "thread exit" event, and therefore does...
case SIGTHREADEXIT:
remove_thread (find_thread_ptid (new_ptid));
lynx_continue (new_ptid);
goto retry;
=> remove_thread causes current_thread to be set to NULL...
(that's the recent change mentioned above)
=> ... which causes problems during lynx_continue, because
it calls lynx_resume, which calls regcache_invalidate,
which unfortunately assumes that CURRENT_THREAD is not NULL:
void
regcache_invalidate (void)
{
/* Only update the threads of the current process. */
SEGV!--> int pid = ptid_get_pid (current_thread->entry.id);
find_inferior (&all_threads, regcache_invalidate_one, &pid);
}
Since the problem at hand is caused by trying to figure out which
inferior to reset the regcache for, and since lynx_resume actually
had that info, this patch fixes the problem by introducing a new
routine called regcache_invalidate_pid, which invalidates the cache
of the given pid; and then modifies lynx_resume use that new routine
rather than relying on regcache_invalidate to invalidate the regcache
of the expected inferior.
gdb/gdbserver/ChangeLog:
* regcache.h (regcache_invalidate_pid): Add declaration.
* regcache.c (regcache_invalidate_pid): New function, extracted
from regcache_invalidate.
(regcache_invalidate): Reimplement using regcache_invalidate_pid.
Add trivial documentation comment.
* lynx-low.c: Use regcache_invalidate_pid instead of
regcache_invalidate.
See the comment added in configure.ac for more details behind
this change.
gdb/gdbserver/ChangeLog:
* configure.ac: Do not call AC_CHECK_TYPES for Elf32_auxv_t
and Elf64_auxv_t if the target is Android.
The target_process_qsupported method is called for each qSupported
feature that the common code does not recognize. The only current
implementation, for x86 Linux (x86_linux_process_qsupported), assumes
that it either is called with the "xmlRegisters=i386" feature, or that
it is isn't called at all, indicating the connected GDB predates x86
XML descriptions.
That's a bad assumption however. If GDB sends in a new/unknown (to
core gdbserver) feature after "xmlRegisters=i386", say, something like
qSupported:xmlRegisters=i386;UnknownFeature+, then when
target_process_qsupported is called for "UnknownFeature+",
x86_linux_process_qsupported clears the 'use_xml' global and calls
x86_linux_update_xmltarget, and gdbserver ends up _not_ reporting a
XML description...
This commit changes the target_process_qsupported API to instead pass
down a vector of unprocessed qSupported features in one go.
(There's an early call to target_process_qsupported(NULL) that
indicates "starting qSupported processing". There's no matching call
to mark the end of processing, though. I first fixed this by passing
(char *)-1 to indicate that, and adjusted the x86 backend to only
clear 'use_xml' when qSupported processing starts, and then only call
x86_linux_update_xmltarget() when (char *)-1 was passed. However, I
wasn't that happy with the hack and came up this alternative version.)
gdb/gdbserver/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_process_qsupported): Change prototype.
Adjust.
* linux-low.h (struct linux_target_ops) <process_qsupported>:
Change prototype.
* linux-x86-low.c (x86_linux_process_qsupported): Change prototype
and adjust to loop over all features.
* server.c (handle_query) <qSupported>: Adjust to call
target_process_qsupported once, passing it a vector of unprocessed
features.
* target.h (struct target_ops) <process_qsupported>: Change
prototype.
(target_process_qsupported): Adjust.
Both x86_64 GNU/Linux and x86_64 mingw-w64 build cleanly with
--enable-targets=all. This enables -Werror by default in C++ mode
too, in order to let the buildbot catch C++ build regressions for us.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* configure.ac (ERROR_ON_WARNING): Don't check whether in C++
mode.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* configure.ac (ERROR_ON_WARNING): Don't check whether in C++
mode.
* configure: Regenerate.
Both x86_64 GNU/Linux and x86_64 mingw-w64 build cleanly with
--enable-targets=all. Let's drop the -fpermissive hack, in order to
let the buildbot catch C++ build regressions for us.
gdb/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* build-with-cxx.m4 (GDB_AC_BUILD_WITH_CXX): Remove -fpermissive.
* configure: Regenerate.
gdb/gdbserver/ChangeLog:
2015-11-19 Pedro Alves <palves@redhat.com>
* configure: Regenerate.
The patch fixes the following errors in C++ build,
gdb/gdbserver/linux-aarch64-low.c: In function 'int emit_data_processing(uint32_t*, aarch64_opcodes, aarch64_register, aarch64_register, aarch64_operand)':
gdb/gdbserver/linux-aarch64-low.c:1071:52: error: invalid conversion from 'unsigned int' to 'aarch64_opcodes' [-fpermissive]
return emit_data_processing_reg (buf, opcode | operand_opcode, rd,
^
gdb/gdbserver:
2015-11-19 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (emit_data_processing_reg): Change opcode
type to uint32_t.
This patch moves the enum definition out of the scope of struct, and
fixes the following error.
gdb/gdbserver/linux-aarch64-low.c:681:18: error: 'OPERAND_REGISTER' was not declared in this scope
operand.type = OPERAND_REGISTER;
^
gdb/gdbserver:
2015-11-19 Yao Qi <yao.qi@linaro.org>
* linux-aarch64-low.c (enum aarch64_operand_type): New.
(struct aarch64_operand): Move enum out.
Commit 91ee7171d0 (MinGW and attribute format(printf/gnu_printf))
made common/common-defs.h depend on gnulib's substitute headers.
Turns out that that broke the gdbserver/ipa build (as the buildbots
discovered) because nothing is making sure that gnulib is built before
the ipa is.
gdb/gdbserver/ChangeLog:
2015-11-18 Pedro Alves <palves@redhat.com>
* Makefile.in (all_object_files): Add $IPA_OBJS.
Building in C++ caught a buglet here:
../../../src/gdb/gdbserver/win32-low.c: In function 'void win32_resume(thread_resume*, size_t)':
../../../src/gdb/gdbserver/win32-low.c:929:11: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
sig = resume_info[0].sig;
^
../../../src/gdb/gdbserver/win32-low.c:934:11: error: invalid conversion from 'int' to 'gdb_signal' [-fpermissive]
sig = 0;
^
Signals in the "struct thread_resume" structure are host signals, not
gdb signals. The current code happens to work because the only
signals that the Windows port supports have the same number as the gdb
equivalent (see handle_exception for the win32 exception -> gdb signal
mapping).
gdb/gdbserver/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* win32-low.c (win32_resume): Use gdb_signal_from_host,
GDB_SIGNAL_0 and gdb_signal_to_string.
Fixes:
../../../src/gdb/gdbserver/win32-low.c: In function 'int win32_kill(int)':
../../../src/gdb/gdbserver/win32-low.c:823:46: error: invalid conversion from 'int' to 'target_waitkind' [-fpermissive]
struct target_waitstatus our_status = { 0 };
^
handle_output_debug_string doesn't use the parameter for anything
(it's an output parameter in the gdb version), so just remove it.
gdb/gdbserver/ChangeLog:
2015-11-17 Pedro Alves <palves@redhat.com>
* win32-low.c (handle_output_debug_string): Remove parameter.
(win32_kill): Remove our_status local and adjust call to
handle_output_debug_string.
(get_child_debug_event): Adjust call to
handle_output_debug_string.
Fixes
/home/simark/src/binutils-gdb/gdb/gdbserver/linux-mips-low.c: In function ‘void mips_add_watchpoint(arch_process_info*, CORE_ADDR, int, int)’:
/home/simark/src/binutils-gdb/gdb/gdbserver/linux-mips-low.c:368:19: error: invalid conversion from ‘int’ to ‘target_hw_bp_type’ [-fpermissive]
new_watch->type = watch_type;
^
gdb/gdbserver/ChangeLog:
* linux-mips-low.c (mips_linux_new_thread): Change type of
watch_type to enum target_hw_bp_type.
Trivial casts for C++.
Fixes things like
In file included from /home/simark/src/binutils-gdb/gdb/gdbserver/../common/common-defs.h:39:0,
from /home/simark/src/binutils-gdb/gdb/gdbserver/server.h:22,
from /home/simark/src/binutils-gdb/gdb/gdbserver/linux-arm-low.c:19:
/home/simark/src/binutils-gdb/gdb/gdbserver/linux-arm-low.c: In function ‘int arm_get_hwcap(long unsigned int*)’:
/home/simark/src/binutils-gdb/gdb/gdbserver/../../include/libiberty.h:711:38: error: invalid conversion from ‘void*’ to ‘unsigned char*’ [-fpermissive]
# define alloca(x) __builtin_alloca(x)
^
/home/simark/src/binutils-gdb/gdb/gdbserver/linux-arm-low.c:807:25: note: in expansion of macro ‘alloca’
unsigned char *data = alloca (8);
^
gdb/gdbserver/ChangeLog:
* linux-aarch32-low.c (arm_fill_gregset): Add cast.
(arm_store_gregset): Likewise.
* linux-arm-low.c (arm_get_hwcap): Likewise.
(arm_read_description): Likewise.
g++ doesn't like that we forward-declare a variable that is initialized
later in the file. It's easy enough to re-order things to fix it.
Fixes
/home/simark/src/binutils-gdb/gdb/gdbserver/linux-ppc-low.c:663:28: error: redefinition of ‘usrregs_info ppc_usrregs_info’
static struct usrregs_info ppc_usrregs_info =
^
/home/simark/src/binutils-gdb/gdb/gdbserver/linux-ppc-low.c:381:28: note: ‘usrregs_info ppc_usrregs_info’ previously declared here
static struct usrregs_info ppc_usrregs_info;
^
gdb/gdbserver/ChangeLog:
* linux-ppc-low.c (ppc_usrregs_info): Remove
forward-declaration.
(ppc_arch_setup): Move lower in file.
Fixes on i386:
../../../binutils-gdb/gdb/gdbserver/proc-service.c: In function ps_pdread:
../../../binutils-gdb/gdb/gdbserver/proc-service.c:83:25: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
../../../binutils-gdb/gdb/gdbserver/proc-service.c: In function ps_pdwrite:
../../../binutils-gdb/gdb/gdbserver/proc-service.c:93:30: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]
I could have kept both casts:
(CORE_ADDR) (uintptr_t) addr
but it's cleaner this way. The uintptr_t implicitely gets promoted to a
CORE_ADDR, which is at least as long as uintptr_t.
gdb/gdbserver/ChangeLog:
* proc-service.c (ps_pdread): Change CORE_ADDR cast to uintptr_t.
(ps_pdwrite): Likewise.
gdb/gdbserver/ChangeLog:
* linux-arm-low.c (arm_new_thread): Move pointer dereference
to after assert checks.
Signed-off-by: Henrik Wallin <henrik.wallin@windriver.com>
The casts are required because ps_pd{read,write} must respect a fixed
interface.
gdb/gdbserver/ChangeLog:
* proc-service.c (ps_pdread): Add/adjust casts.
(ps_pdwrite): Add/adjust casts.
... for C++.
Fixes:
gdb/gdbserver/mem-break.c:204:28: error: invalid conversion from 'int' to 'bkpt_type' [-fpermissive]
gdb/gdbserver/ChangeLog:
2015-10-29 Pedro Alves <palves@redhat.com>
* mem-break.c (Z_packet_to_bkpt_type): Add cast.
... as needed for C++.
tpoint->handle is a generic 'void *' handle.
gdb/gdbserver/ChangeLog:
2015-10-29 Pedro Alves <palves@redhat.com>
* tracepoint.c (clear_installed_tracepoints): Add casts.
This is code parsing RSP signal numbers, checking whether the numbers
are indeed valid/known GDB signals, and then converting to host signal
numbers. I considered adding temporary enum gdb_signal variables
instead, but didn't really like the result.
gdb/gdbserver/ChangeLog:
2015-10-29 Pedro Alves <palves@redhat.com>
* server.c (handle_v_cont, process_serial_event): Add enum
gdb_signal casts to signal parsing code.
Fixes:
../../../src/gdb/gdbserver/linux-low.c: In function ‘int linux_low_read_btrace(btrace_target_info*, buffer*, int)’:
../../../src/gdb/gdbserver/linux-low.c:6827:48: error: invalid conversion from ‘int’ to ‘btrace_read_type’ [-fpermissive]
err = linux_read_btrace (&btrace, tinfo, type);
^
In file included from ../../../src/gdb/gdbserver/linux-low.c:98:0:
../../../src/gdb/gdbserver/../nat/linux-btrace.h:116:26: error: initializing argument 3 of ‘btrace_error linux_read_btrace(btrace_data*, btrace_target_info*, btrace_read_type)’ [-fpermissive]
extern enum btrace_error linux_read_btrace (struct btrace_data *btrace,
^
The cyclic dependency the comment talks about is no longer relevant:
https://sourceware.org/ml/gdb-patches/2015-10/msg00643.html
gdb/gdbserver/ChangeLog:
2015-10-29 Pedro Alves <palves@redhat.com>
* linux-low.c (linux_low_read_btrace): Change type of 'type'
parameter.
* server.c (handle_qxfer_btrace): Change type of 'type'
local.
* target.h (struct target_ops) <read_btrace>: Change type of
'type' parameter. Update comment.
Josh Stone
Antoine Tremblay
Pedro Alves
Simon Marchi
Joel Brobecker
Doug Evans
Yao Qi
Simon Marchi
Henrik Wallin