This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDBserver disconnected tracing support


On Sun, Apr 11, 2010 at 9:54 AM, Pedro Alves <pedro@codesourcery.com> wrote:
> I've applied this to implement disconnected tracing support
> in GDBserver. ?This means, you can disconnect GDB from
> GDBserver, leaving the trace running, and connect back
> later to check what happened.
>
> When a tracing is ongoing, and the disconnected tracing
> setting is on, when GDB asks gdbserver to detach
> from a process, gdbserver actually doesn't detach from
> the process, but stays attached in a special mode that
> still handles tracepoints, and, forwards all other
> signals back to the inferior.
>
> Implementation wise, this required a few changes:
>
> ?- In this mode, GDBserver needs to be able to wait for an
> ? incoming connection from GDB, and, handle target events
> ? simultaneously. ?The current code blocks on `accept' waiting
> ? for a new connection. ?Instead of blocking, accepting a new
> ? connection is handled by registering the accept socket in
> ? the event loop, as a waitable file descriptor, and handling
> ? the new connection with an event callback. ?This way, everything
> ? goes through the event loop, new sockets, gdb traffic, and target
> ? events. ?The target also needs to be forced into asynchronous
> ? even reporting mode.
>
> ?- I needed to be able to access the exiting process object after
> ? the target having reported to gdbserver common code (through the
> ? `wait' interface, TARGET_WAITKIND_EXITED|SIGNALLED) it had exited.
> ? This cried for adding a target_mourn_inferior equivalent to GDBserver.
> ? And so I did that. ?This also cleaned up thread-db.c a bit, by
> ? splitting the thread_db_free function in two
> ? (thread_db_detach+disable_thread_event_reporting/thread_db_mourn).
> ? This now looks a ?bit more like native GDB's linux-thread-db.c
> ? similar code, and saner, IMO.
>
> ?- I needed to have to able to stop all threads when a new GDB connection
> ? arrives in all-stop mode. ?Hence, the new pause_all method, to expose
> ? stop-all-threads functionality to common gdbserver code. ?This may one
> ? day evolve into always having the linux low target in non-stop/async mode.
>
> ?- I needed a way for a event-loop handler callback to tell the event-loop
> ? to stop processing immediately. ?I've done that by adding the option
> ? of the callback returning -1 to signal just that. ?This also allowed
> ? me to easily unbreak "(gdb) monitor exit", which wasn't really causing
> ? a gdbserver exit presently (seems like I broke it when I added the
> ? event-loop.c based event-loop a while back :-/)
>
> ?- I moved the `last_resume_kind' field from lwp_info to
> ? thread_info (that is, to common code), since common code
> ? needed to tweak it. ?Since not all targets handle the flag
> ? yet, I've guarded the expectation that the flag contains
> ? anything useful behind the target having a thread_stopped
> ? callback installed as well. ?This check will ideally be
> ? removed at some point, and the `last_resume_kind' flag
> ? would ideally be all handled by common code.
>
> ?- There's a possible race between GDB telling gdbserver to
> ? detach a process, and actually closing the socket. ?In the
> ? race window, we could end up handling a target event, and
> ? trying to push it down to GDB. ?To handle that, I've
> ? added a new `process_info->gdb_detached' flag. ?Don't
> ? push events to GDB if that flag is set. ?This may be
> ? also used in the future when tracing is defined to
> ? work with multi-process, as then we may potentially
> ? be able to have GDB detach from a process for disconnected
> ? tracing while still debugging other processes.
>
> No regressions on x86_64-linux.
>

This caused:

On Linux/x86-64, I saw

FAIL: gdb.server/ext-attach.exp: attach to remote program 2
FAIL: gdb.server/ext-attach.exp: backtrace 2

They weren't there on April 11, 2010. I got

gnu-18:pts/4[18]> ./gdbserver-old --multi gnu-18:10000
Listening on port 10000
Remote debugging from host 172.25.70.137
readchar: Got EOF
Remote side has terminated connection.  GDBserver will reopen the connection.
Listening on port 10000
Remote debugging from host 172.25.70.137
Process 64 created; pid = 25716
Detaching from process 25716
1.100000
Cannot attach to lwp 25716: Operation not permitted (1)





-- 
H.J.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]