| B(3pm) | Perl Programmers Reference Guide | B(3pm) |
B - The Perl Compiler Backend
use B;
The "B" module supplies classes which allow a Perl program to delve into its own innards. It is the module used to implement the "backends" of the Perl compiler. Usage of the compiler does not require knowledge of this module: see the O module for the user-visible part. The "B" module is of use to those who want to write new compiler backends. This documentation assumes that the reader knows a fair amount about perl's internals including such things as SVs, OPs and the internal symbol table and syntax tree of a program.
The "B" module contains a set of utility functions for querying the current state of the Perl interpreter; typically these functions return objects from the B::SV and B::OP classes, or their derived classes. These classes in turn define methods for querying the resulting objects about their own internal state.
The "B" module exports a variety of functions: some are simple utility functions, others provide a Perl program with a way to get an initial "handle" on an internal object.
For descriptions of the class hierarchy of these objects and the methods that can be called on them, see below, "OVERVIEW OF CLASSES" and "SV-RELATED CLASSES".
The returned object will only be valid as long as the underlying OPs and SVs continue to exist. Do not attempt to use the object after the underlying structures are freed.
PREFIX is the name of the SYMREF you're walking.
For example:
# Walk CGI's symbol table calling print_subs on each symbol.
# Recurse only into CGI::Util::
walksymtable(\%CGI::, 'print_subs',
sub { $_[0] eq 'CGI::Util::' }, 'CGI::');
print_subs() is a B::GV method you have declared. Also see "B::GV Methods", below.
For descriptions of the class hierarchy of these objects and the methods that can be called on them, see below, "OVERVIEW OF CLASSES" and "OP-RELATED CLASSES".
my $op_type = $optype[$op_type_num];
A simple mapping of the op type number to its type (like 'COP' or 'BINOP').
my $sv_name = $specialsv_name[$sv_index];
Certain SV types are considered 'special'. They're represented by B::SPECIAL and are referred to by a number from the specialsv_list. This array maps that number back to the name of the SV (like 'Nullsv' or '&PL_sv_undef').
The C structures used by Perl's internals to hold SV and OP information (PVIV, AV, HV, ..., OP, SVOP, UNOP, ...) are modelled on a class hierarchy and the "B" module gives access to them via a true object hierarchy. Structure fields which point to other objects (whether types of SV or types of OP) are represented by the "B" module as Perl objects of the appropriate class.
The bulk of the "B" module is the methods for accessing fields of these structures.
Note that all access is read-only. You cannot modify the internals by using this module. Also, note that the B::OP and B::SV objects created by this module are only valid for as long as the underlying objects exist; their creation doesn't increase the reference counts of the underlying objects. Trying to access the fields of a freed object will give incomprehensible results, or worse.
B::IV, B::NV, B::PV, B::PVIV, B::PVNV, B::PVMG, B::PVLV, B::AV, B::HV, B::CV, B::GV, B::FM, B::IO. These classes correspond in the obvious way to the underlying C structures of similar names. The inheritance hierarchy mimics the underlying C "inheritance":
B::SV
|
+------------+------------+
| | |
B::PV B::IV B::NV
/ \ / /
/ \ / /
B::INVLIST B::PVIV /
\ /
\ /
\ /
B::PVNV
|
|
B::PVMG
|
+-------+-------+---+---+-------+-------+
| | | | | |
B::AV B::GV B::HV B::CV B::IO B::REGEXP
| |
| |
B::PVLV B::FM
Access methods correspond to the underlying C macros for field access, usually with the leading "class indication" prefix removed (Sv, Av, Hv, ...). The leading prefix is only left in cases where its removal would cause a clash in method name. For example, "GvREFCNT" stays as-is since its abbreviation would clash with the "superclass" method "REFCNT" (corresponding to the C function "SvREFCNT").
It is the appropriate method to use if you need to get the name of a lexical variable from a padname array. Lexical variable names are always stored with a null terminator, and the length field (CUR) is overloaded for other purposes and can't be relied on here.
It's useful if you want to print out the name of a variable. If you restrict yourself to globs which exist at compile-time then the result ought to be unambiguous, because code like "${"^G"} = 1" is compiled as two ops - a constant string and a dereference (rv2gv) - so that the glob is created at runtime.
If you're working with globs at runtime, and need to disambiguate *^G from *{"^G"}, then you should use the raw NAME method.
B::IO objects derive from IO objects and you will get more information from the IO object itself.
For example:
$gvio = B::svref_2object(\*main::stdin)->IO; $IO = $gvio->object_2svref(); $fd = $IO->fileno();
- STDIN/OUT
I STDIN/OUT/ERR
< read-only
> write-only
a append
+ read and write
s socket
| pipe
I IMPLICIT
# NUMERIC
space closed handle
\0 closed internal handle
"B::OP", "B::UNOP", "B::UNOP_AUX", "B::BINOP", "B::LOGOP", "B::LISTOP", "B::PMOP", "B::SVOP", "B::PADOP", "B::PVOP", "B::LOOP", "B::COP", "B::METHOP".
These classes correspond in the obvious way to the underlying C structures of similar names. The inheritance hierarchy mimics the underlying C "inheritance":
B::OP
|
+----------+---------+--------+-------+---------+
| | | | | |
B::UNOP B::SVOP B::PADOP B::COP B::PVOP B::METHOP
|
+---+---+---------+
| | |
B::BINOP B::LOGOP B::UNOP_AUX
|
|
B::LISTOP
|
+---+---+
| |
B::LOOP B::PMOP
Access methods correspond to the underlying C structure field names, with the leading "class indication" prefix ("op_") removed.
These methods get the values of similarly named fields within the OP data structure. See top of "op.h" for more info.
Note that the global variable $B::OP::does_parent is undefined on older perls that don't support the "parent" method, is defined but false on perls that support the method but were built without "-DPERL_OP_PARENT", and is true otherwise.
The "B::COP" class is used for "nextstate" and "dbstate" ops. As of Perl 5.22, it is also used for "null" ops that started out as COPs.
Perl 5.18 introduced a new class, B::PADLIST, returned by B::CV's "PADLIST" method.
Perl 5.22 introduced the B::PADNAMELIST and B::PADNAME classes.
Although the optree is read-only, there is an overlay facility that allows you to override what values the various B::*OP methods return for a particular op. $B::overlay should be set to reference a two-deep hash: indexed by OP address, then method name. Whenever a an op method is called, the value in the hash is returned if it exists. This facility is used by B::Deparse to "undo" some optimisations. For example:
local $B::overlay = {};
...
if ($op->name eq "foo") {
$B::overlay->{$$op} = {
name => 'bar',
next => $op->next->next,
};
}
...
$op->name # returns "bar"
$op->next # returns the next op but one
Malcolm Beattie, "mbeattie@sable.ox.ac.uk"
| 2019-10-21 | perl v5.30.3 |