AnyEvent-GDB
view release on metacpan or search on metacpan
=head1 NAME
AnyEvent::GDB - asynchronous GDB machine interface interface
=head1 SYNOPSIS
use AnyEvent::GDB;
=head1 DESCRIPTION
This module is an L<AnyEvent> user, you need to make sure that you use and
run a supported event loop.
It implements the GDB MI protocol, which can be used to talk to GDB
without having to parse the ever changing command syntax aimed at humans.
It properly quotes your commands and parses the data structures returned
by GDB.
At the moment, it's in an early stage of development, so expect changes,
and, over time, further features (such as breakpoint-specific callbacks
and so on).
=head1 EXAMPLE PROGRAM
To get you started, here is an example program that runs F</bin/ls>,
displaying the stopped information when hitting a breakpoint on C<_exit>:
use Data::Dump;
use AnyEvent::GDB;
our $gdb = new AnyEvent::GDB
trace => 1,
on_exec_stopped => sub {
ddx $_[0];
},
;
my $done
ddx $gdb->cmd_sync (file_exec_and_symbols => "/bin/ls");
ddx $gdb->cmd_sync (break_insert => "_exit");
ddx $gdb->cmd_sync ("exec_run");
AE::cv->recv;
=head2 PROTOCOL QUIRKS
=head3 Minus vs. underscores
The MI protocol uses C<-> to separate name components, while in Perl, you
use C<_> for this purpose.
This module usually accepts either form as input, and always converts
names with C<-> to names with C<_>, so the C<library-loaded> notify might
become C<notify_library_loaded>, and the C<host-name> result in that event
is stored in the C<host_name> hash element in Perl.
=head3 Output redirection
Unfortunately, GDB has no (portable) provision to separate GDB
input/output from program input/output. Obviously, without a distinction
between program I/O and GDB I/O it becomes impossible to safely control
GDB.
There are two ways for you around it: redirect stdin/stdout yourself, or
set a tty (eg. with the C<inferior_set_tty> command).
Unfortunately, the MI interface does not seem to support any kind
of I/O redirection, so this module helps you a bit, by setting the
C<exec-wrapper> variable with a console C<set> commmand. That is, this
module does soeQmthing like the following for you, providing proper file
descriptors for your actual stdin and stdout:
set exec-wrapper <&5 >&6
The actual I/O redirection operators are also stored in C<< $gdb->{stdio}
>>, so you can even do it yourself, e.g. when providing your own wrapper:
$self->cmd_raw ("set exec-wrapper $self->{stdio}", sub { });
The remaining arguments, excluding the last one, are simply the parameters
passed to GDB.
All options and parameters will be properly quoted.
When the command is done, the callback C<$cb> will be invoked with
C<$class> being one of C<done>, C<connected>, C<error> or C<exit>
(note: not C<running>), C<$results> being a has reference with all the
C<variable=value> pairs from the result list.
C<$console> is an array reference with all the GDB console messages
written while command executes (for MI commands, this should always be
C<undef> and can be ignored).
Example: #todo#
=cut
sub cmd {
my $cb = pop;
my ($self, $cmd, @arg) = @_;
$cmd =~ s/^[\-_]?/_/;
$cmd =~ y/_/-/;
$cmd .= " ";
my $opt = ref $arg[0] ? shift @arg : [];
for (@$opt) {
$cmd .= "-";
$cmd .= (_q $_) . " "
for (ref) ? @$_ : $_;
}
# the MI syntax is inconsistent, providing "--" in case
# parameters start with "-", but not allowing "-" as first
# char of a parameter. in fact, "--" is flagged as unknown
# option.
if (@arg) {
# $cmd .= "-- ";
$cmd .= (_q $_) . " "
for @arg;
}
# remove trailing " "
substr $cmd, -1, 1, "";
$self->cmd_raw ($cmd, $cb);
}
=item ($results, $console) = $gdb->cmd_sync ($command => [$option...], $parameter...])
=item $results = $gdb->cmd_sync ($command => [$option...], $parameter...])
Like C<cmd>, but blocks execution until the command has been executed, and
returns the results if sucessful. Croaks when GDB returns with an error.
This is purely a convenience method for small scripts: since it blocks
execution using a condvar, it is not suitable to be used inside callbacks
or modules.
That is, unless L<Coro> is used - with Coro, you can run multiple
C<cmd_sync> methods concurrently form multiple threads, with no issues.
=cut
sub cmd_sync {
push @_, my $cv = AE::cv;
&cmd;
my ($class, $results, $console) = $cv->recv;
Carp::croak $results->{msg}
if $class eq "error";
wantarray ? ($results, $console) : $results
}
sub event {
my ($self, $event, @args) = @_;
# if ($self->{verbose}) {
# use Data::Dumper;
# print Data::Dumper
# ->new ([[$event, @args]])
# ->Pair ("=>")
# ->Useqq (1)
# ->Indent (0)
# ->Terse (1)
# ->Quotekeys (0)
# ->Sortkeys (1)
# ->Dump,
# "\n";
# }
my $cb;
$cb = $self->can ("on_event") and $cb->($self, $event, @args);
$cb = $self-> {on_event} and $cb->($self, $event, @args);
$cb = $self->can ("on_$event") and $cb->($self, $event, @args);
$cb = $self-> {"on_$event"} and $cb->($self, $event, @args);
}
# predefined events
sub on_notify_thread_group_added {
my ($self, undef, $r) = @_;
$self->{thread_group}{$r->{id}} = $r;
}
sub on_notify_thread_group_removed {
my ($self, undef, $r) = @_;
delete $self->{thread_group}{$r->{id}};
}
sub on_notify_thread_group_started {
my ($self, undef, $r) = @_;
}
# $self->event ("thread_$r->{reason}" => $r, [map $_->{id}, $self->_threads ($r)]);
}
sub _thread_groups {
my ($self, $r) = @_;
exists $r->{thread_group}
? $self->{thread_group}{$r->{thread_group}}
: values %{ $self->{thread_group} }
}
sub on_notify_library_loaded {
my ($self, undef, $r) = @_;
$_->{library}{$r->{id}} = $r
for $self->_thread_groups ($r);
}
sub on_notify_library_unloaded {
my ($self, undef, $r) = @_;
delete $_->{library}{$r->{id}}
for $self->_thread_groups ($r);
}
=back
=head2 EVENTS
AnyEvent::GDB is asynchronous in nature, as the goal of the MI interface
is to be fully asynchronous. Due to this, a user of this interface must
be prepared to handle various events.
When an event is produced, the GDB object will look for the following four
handlers and, if found, will call each one in order with the GDB object
and event name (without C<on_>) as the first two arguments, followed by
any event-specific arguments:
=over 4
=item on_event method on the GDB object
Useful when subclassing.
=item on_event constructor parameter/object member
The callback specified as C<on_event> parameter to the constructor.
=item on_EVENTNAME method on the GDB object
Again, mainly useful when subclassing.
=item on_EVENTNAME constructor parameter/object member
Any callback specified as C<on_EVENTNAME> parameter to the constructor.
=back
You can change callbacks dynamically by simply replacing the corresponding
C<on_XXX> member in the C<$gdb> object:
$gdb->{on_event} = sub {
# new event handler
};
Here's the list of events with a description of their arguments.
=over 4
=item on_eof => $cb->($gdb, "eof")
Called whenever GDB closes the connection. After this event, the object is
partially destroyed and must not be accessed again.
=item on_target => $cb->($gdb, "target", $string)
Output received from the target. Normally, this is sent directly to STDOUT
by GDB, but remote targets use this hook.
=item on_log => $cb->($gdb, "log", $string)
Log output from GDB. Best printed to STDOUT in interactive sessions.
=item on_TYPE => $cb->($gdb, "TYPE", $class, $results)
Called for GDB C<exec>, C<status> and C<notify> event (TYPE is one of
these three strings). C<$class> is the class of the event, with C<->
replaced by C<_> everywhere.
For each of these, the GDB object will create I<two> events: one for TYPE,
and one for TYPE_CLASS. Usuaully you should provide the more specific
event (TYPE_CLASS).
=item on_TYPE_CLASS => $cb->($gdb, "TYPE_CLASS", $results)
Called for GDB C<exec>, C<status> and C<notify> event: TYPE is one
of these three strings, the class of the event (with C<-> replaced b
C<_>s) is appended to it to form the TYPE_CLASS (e.g. C<exec_stopped> or
C<notify_library_loaded>).
=back
=head2 STATUS STORAGE
The default implementations of the event method store the thread,
thread_group, recording, library and running status insid ethe C<$gdb>
object.
You can access these at any time. Specifically, the following information
is available:
=over 4
=item C<< $gdb->{thread_group}{I<id>} >>
The C<thread_group> member stores a hash for each existing thread
group. The hash always contains the C<id> member, but might also contain
other members.
( run in 0.957 second using v1.01-cache-2.11-cpan-cdf2f3d4e48 )