This is the mail archive of the gdb-testers@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]

[binutils-gdb] Identify remote fork event support


*** TEST RESULTS FOR COMMIT 89245bc05692aaa107fa2884c032da21682edc72 ***

Author: Don Breazeal <donb@codesourcery.com>
Branch: master
Commit: 89245bc05692aaa107fa2884c032da21682edc72

Identify remote fork event support
This patch implements a mechanism for GDB to determine whether fork
events are supported in gdbserver.  This is a preparatory patch for
remote fork and exec event support.

Two new RSP packets are defined to represent fork and vfork event
support.  These packets are used just like PACKET_multiprocess_feature
to denote whether the corresponding event is supported.  GDB sends
fork-events+ and vfork-events+ to gdbserver to inquire about fork
event support.  If the response enables these packets, then GDB
knows that gdbserver supports the corresponding events and will
enable them.

Target functions used to query for support are included along with
each new packet.

In order for gdbserver to know whether the events are supported at the
point where the qSupported packet arrives, the code in nat/linux-ptrace.c
had to be reorganized.  Previously it would test for fork/exec event
support, then enable the events using the pid of the inferior.  When the
qSupported packet arrives there may not be an inferior.  So the mechanism
was split into two parts: a function that checks whether the events are
supported, called when gdbserver starts up, and another that enables the
events when the inferior stops for the first time.

Another gdbserver change was to add some global variables similar to
multi_process, one per new packet.  These are used to control whether
the corresponding fork events are enabled.  If GDB does not inquire
about the event support in the qSupported packet, then gdbserver will
not set these "report the event" flags.  If the flags are not set, the
events are ignored like they were in the past.  Thus, gdbserver will
never send fork event notification to an older GDB that doesn't
recognize fork events.

Tested on Ubuntu x64, native/remote/extended-remote, and as part of
subsequent patches in the series.

gdb/gdbserver/ChangeLog:

        * linux-low.c (linux_supports_fork_events): New function.
        (linux_supports_vfork_events): New function.
        (linux_target_ops): Initialize new structure members.
        (initialize_low): Call linux_check_ptrace_features.
        * lynx-low.c (lynx_target_ops): Initialize new structure
        members.
        * server.c (report_fork_events, report_vfork_events):
        New global flags.
        (handle_query): Add new features to qSupported packet and
        response.
        (captured_main): Initialize new global variables.
        * target.h (struct target_ops) <supports_fork_events>:
        New member.
        <supports_vfork_events>: New member.
        (target_supports_fork_events): New macro.
        (target_supports_vfork_events): New macro.
        * win32-low.c (win32_target_ops): Initialize new structure
        members.

gdb/ChangeLog:

        * nat/linux-ptrace.c (linux_check_ptrace_features): Change
        from static to extern.
        * nat/linux-ptrace.h (linux_check_ptrace_features): Declare.
        * remote.c (anonymous enum): <PACKET_fork_event_feature,
        * PACKET_vfork_event_feature>: New enumeration constants.
        (remote_protocol_features): Add table entries for new packets.
        (remote_query_supported): Add new feature queries to qSupported
        packet.
        (_initialize_remote): Exempt new packets from the requirement
        to have 'set remote' commands.


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