Lines Matching +refs:gdb +refs:stack +refs:buffer
196 to fetch the SV's raw internal buffer. This is tricky, though; if your Perl
258 If you want to write to an existing SV's buffer and set its value to a
262 used, for example, to append data from an API function to a buffer
299 If you have a buffer allocated with Newx() and want to set that as the
301 if you want to avoid perl re-allocating the buffer to fit the trailing
442 Hence, at this point, the start of the buffer that we allocated lives
449 the current implementation, the final byte of a string buffer is used as a
450 copy-on-write reference count. If the buffer is not big enough, then
478 buffer happens to have changed to "\1" here, not "1", because the current
479 implementation stores the offset count in the string buffer. This is
1063 For a reference to be mortal means that it is owned by the temps stack,
1074 main stack. The stack is problematic for reference tracking, because it
1077 destroyed while referenced by the stack, because the stack's uncounted
1079 (uncounted) reference on the stack, it is vitally important to ensure that
1085 especially to be put on the stack and would otherwise be unreferenced.
1097 from the caller to the temps stack. Because C<sv_newmortal> gives the new
1326 You can force an SV to make its own copy of its string buffer by calling C<sv_force_normal(sv)> or SvPV_force_nolen(sv).
1328 If you want to make the SV drop its string buffer, use
1337 C<-Accflags=-DPERL_DEBUG_READONLY_COW> and it will turn buffer violations
1656 sv_magic, so you can safely allocate it on the stack.
1909 stack. Later when the current I<pseudo-block> is completed the value
1922 and stored on the save stack. Later when the current I<pseudo-block> is
2041 The current offset on the Perl internal stack (cf. C<SP>) is restored
2109 An XSUB routine will have a stack that contains the arguments from the Perl
2112 The stack arguments are accessible through the C<ST(n)> macro, which returns
2113 the C<n>'th stack argument. Argument 0 is the first argument passed in the
2119 argument stack is not already long enough to handle all the return values.
2123 To handle this situation, the PPCODE directive is used and the stack is
2128 where C<SP> is the macro that represents the local copy of the stack pointer,
2129 and C<num> is the number of elements the stack should be extended by.
2131 Now that there is room on the stack, values can be pushed on it using C<PUSHs>
2148 An alternate (and possibly simpler) method to pushing values on the stack is
2153 This macro automatically adjusts the stack for you, if needed. Thus, you
2154 do not need to call C<EXTEND> to extend the stack.
2159 C<m(X)PUSH[iunp]> macros instead; see L</Putting a C value on Perl stack>.
2203 on the Perl stack.
2210 must manipulate the Perl stack. These include the following macros and
2228 =head2 Putting a C value on Perl stack
2231 stack machine) put an SV* on the stack. However, as an optimization
2238 an integer, a double, or a string on the stack, it just sets the
2239 corresponding parts of its I<target> and puts the I<target> on stack.
2241 The macro to put this target on stack is C<PUSHTARG>, and it is
2246 values on the stack. The following code will not do what you think:
2252 the stack; set C<TARG> to 20, push a pointer to C<TARG> onto the stack".
2253 At the end of the operation, the stack does not contain the values 10
2260 SV* on the stack, which, as noted under L</XSUBs and the Argument Stack>,
2263 C<(X)PUSHmortal>), pushing that onto the stack (extending it if necessary
2362 These three macros are used to change a memory buffer size or to free a
2680 pushed onto the save stack by this hook will be popped just before the
2686 stack. I<o> is the root of the optree representing the scope; it is a
2692 stack. I<o> is as above. Note that it is possible for calls to C<pre_>
2693 and C<post_end> to nest, if there is something on the save stack that
2748 (gdb) print Perl_dump_packsubs(PL_defstash)
3723 takes the appropriate number of values from the stack, and you are
3724 responsible for adding stack marks if necessary.
3826 Descriptions above occasionally refer to "the stack", but there are in fact
3827 many stack-like data structures within the perl interpreter. When otherwise
3828 unqualified, "the stack" usually refers to the value stack.
3835 This stack stores the values that regular perl code is operating on, usually
3836 intermediate values of expressions within a statement. The stack itself is
3839 The base of this stack is pointed to by the interpreter variable
3842 =for apidoc_section $stack
3845 The head of the stack is C<PL_stack_sp>, and points to the most
3850 Items are pushed to the stack by using the C<PUSHs()> macro or its variants
3853 check the size of the stack and assume it to be big enough. These must be
3854 paired with a suitable check of the stack's size, such as the C<EXTEND> macro
3874 may have had reason to move the stack or push/pop values to it, you must use
3878 Items are popped from the stack by using the C<POPs> macro or its typed
3882 =for apidoc_section $stack
3885 Note specifically that SV pointers on the value stack do not contribute to the
3887 being pushed to the stack you must arrange for them to be destroyed at a
3893 The value stack stores individual perl scalar values as temporaries between
3895 we need to know where on the stack each list begins. This is the purpose of the
3896 mark stack.
3898 The mark stack stores integers as I32 values, which are the height of the
3899 value stack at the time before the list began; thus the mark itself actually
3900 points to the value stack entry one before the list. The list itself starts at
3903 The base of this stack is pointed to by the interpreter variable
3906 =for apidoc_section $stack
3909 The head of the stack is C<PL_markstack_ptr>, and points to the most
3914 Items are pushed to the stack by using the C<PUSHMARK()> macro. Even though
3915 the stack itself stores (value) stack indices as integers, the C<PUSHMARK>
3916 macro should be given a stack pointer directly; it will calculate the index
3922 Items are popped from the stack by the C<POPMARK> macro. There is also a macro
3926 marked stack slot; this is the usual macro that C code will use when operating
3927 on lists given on the stack.
3930 pushed value on the value stack before the list begins, and so the list itself
3941 Because the C<mark> variable is converted to a pointer on the value stack,
3943 invoked within the function, because the stack may need to be moved to
3946 track the mark itself later on after the stack had been moved.
3956 As noted above, xV references on the main value stack do not contribute to the
3958 temporary values which live on the stack must be released. This is the job of
3959 the temporaries stack.
3961 The temporaries stack stores pointers to xVs whose reference counts will be
3964 The base of this stack is pointed to by the interpreter variable
3967 =for apidoc_section $stack
3970 The head of the stack is indexed by C<PL_tmps_ix>, an integer which stores the
3975 There is no public API to directly push items to the temporaries stack. Instead,
3977 address to the temporaries stack.
3979 Likewise, there is no public API to read values from the temporaries stack.
3981 macro establishes the base levels of the temporaries stack, by capturing the
3983 value to the save stack. Thereafter, whenever C<FREETMPS> is invoked all of
3986 =for apidoc_section $stack
3999 The save stack is used by perl to implement the C<local> keyword and other
4001 leaving the current scope. Items pushed to this stack generally capture the
4007 (usually SV pointers or integers), the items pushed to the save stack are
4015 =for apidoc_section $stack
4018 Instead, the stack stores information in a variable-length encoding of C<ANY>
4023 from the stack.
4025 The base of this stack is pointed to by the interpreter variable
4028 =for apidoc_section $stack
4031 The head of the stack is indexed by C<PL_savestack_ix>, an integer which
4036 =for apidoc_section $stack
4039 Items are pushed to the save stack by using the various C<SAVE...()> macros.
4041 value on the save stack, ensuring that value gets restored on scope exit.
4051 Others include C<SAVEFREEPV> which arranges for a PV (i.e. a string buffer) to
4057 stack. Instead, via the scope stack, the C<ENTER> and C<LEAVE> pair form a way
4064 As with the mark stack to the value stack, the scope stack forms a pair with
4065 the save stack. The scope stack stores the height of the save stack at which
4066 nested scopes begin, and allows the save stack to be unwound back to that
4070 stack storing human-readable string names describing the type of stack
4072 stack, and each pop operation checks the topmost name with what is expected,
4075 The base of this stack is pointed to by the interpreter variable
4076 C<PL_scopestack>, of type C<I32 *>. If enabled, the scope stack names are
4080 =for apidoc_section $stack
4084 The head of the stack is indexed by C<PL_scopestack_ix>, an integer which
4089 =for apidoc_section $stack
4092 Values are pushed to the scope stack using the C<ENTER> macro, which begins a
4093 new nested scope. Any items pushed to the save stack are then restored at the
4101 =head2 Introduction to the context stack
4109 stack, which is an array of C<PERL_CONTEXT> structures, and which is
4112 context entry is pushed onto the stack. Similarly when leaving a block or
4114 context stack represents the current dynamic scope, it can be searched.
4115 For example, C<next LABEL> searches back through the stack looking for a
4118 the stack.
4161 The macro C<cxstack> returns the base of the current context stack, while
4162 C<cxstack_ix> is the index of the current frame within that stack.
4168 In fact, the context stack is actually part of a stack-of-stacks system;
4170 handler, a new stack is pushed, then popped at the end.
4177 saving the savestack and temps stack positions, and required additional
4196 A typical context stack pushing can be found in C<pp_entersub>; the
4207 /* ... make mortal copies of stack args which are PADTMPs here ... */
4250 Note that C<cx_pushblock()> sets two new floors: for the args stack (to
4251 C<MARK>) and the temps stack (to C<PL_tmps_ix>). While executing at this
4253 tmps stack levels to these floors. Note that since C<cx_pushblock> uses
4259 Most callers of C<cx_pushblock> simply set the new args stack floor to the
4260 top of the previous stack frame, but for C<CXt_LOOP_LIST> it stores the
4261 items being iterated over on the stack, and so sets C<blk_oldsp> to the
4275 C<cx_pushblock>, where nothing needs pushing on the save stack,
4279 rather than on the save stack; it's much faster that way.
4284 stack unwinding code in C<dounwind> would see (in the example above) a
4299 decrement the current context stack index; this is done separately using
4348 this copy before the save stack is popped or variables are restored, or
4358 shifting args down the stack, and only processing those entries on the
4359 temps stack that are safe to do so.
4371 context stack frame will be re-processed. Thus it is vital that all steps
4413 Finally, the context stack pointer is actually decremented by C<CX_POP(cx)>.
4416 and C<DESTROY> are supposed to work within a new context stack, it's best
4433 =head1 Reference-counted argument stack
4439 stack have their reference counts adjusted. It is intended that eventually
4442 The macros which manipulate the stack such as PUSHs() and POPs() don't
4444 something else is keeping the SV alive while on the argument stack, such
4445 a pointer from the TEMPs stack, or from the pad (e.g. a lexical variable
4456 argument stack increment the reference count (RC) of the SV by one.
4459 have been written assuming a non reference-counted stack (non-RC for
4460 short), are called via special wrapper functions which adjust the stack
4491 =head2 Reference counted stack states
4493 In the new regime, the current argument stack can be in one of three
4502 In this case, perl will assume when emptying the stack (such as during a
4511 All the items on the stack are reference counted, and will be freed by
4513 state of the stack in C<PERL_RC_STACK> builds.
4519 In this case, items on the stack from the index C<si_stack_nonrc_base>
4528 Note that perl uses a stack-of-stacks, and the AvREAL() and
4529 C<si_stack_nonrc_base> states are per stack. When perl starts up, the main
4530 stack is RC, but by default, new stacks pushed in XS code via PUSHSTACKi()
4533 allows you to specify that the new stack should be RC by default.
4540 CALLRUNOPS(), it will check the current state of the stack, and if it's
4542 entering the main runops loop. Then if necessary it will restore the stack
4546 the runops loop, no matter what the current stack state is.
4549 to handle both stack types. So there are a few places in core - call_sv(),
4591 the stack contents, then calls the hidden real body of the PP function,
4592 then on return, adjusts the stack back.
4602 PP_wrapped(pp_add, 2, 0); /* consumes two args off the stack */
4612 expects three arguments. On entry the stack may look like:
4618 current stack position using C<si_stack_nonrc_base>, then, based on the
4625 pops them off the stack, and pushes some result SVs. None of this
4626 manipulation adjusts any RCs. On return to pp_wrap(), the stack may look
4633 the stack as:
4641 mark stack is examined (and adjusted) in order to determine the number of
4645 different RC states. Perl starts off with an RC stack. Then for example,
4646 pp_entersub() is called, which (via xs_wrap()) splits the stack and
4648 PUSHSTACKi(), which creates a new non-RC stack, then calls call_sv(), which
4649 does CALLRUNOPS(), which causes the new stack to temporarily become RC.
4650 Then a tied method is called, which pushes a new RC stack, and so on. (XXX
4651 currently tied methods actually push a non-RC stack. To be fixed soon).
4665 The traditional PP stack API consisted of a C<dSP> declaration, plus a
4666 number of macros to push, pop and extend the stack. A I<very simplified>
4706 the stack (formerly, they tended to be on the TEMPs stack too). So in code
4728 left on the stack I<until they are finished with>, then removed and their
4734 IV right = SvIV(PL_stack_sp[ 0]); // NB: arguments left on stack
4741 The rpp_replace_2_1() function pops two values off the stack and pushes
4789 removed from the stack are non-NULL, and so are slightly more efficient:
4843 it replaces an SV at an address in the stack rather than at the top.
4861 pops the stack back to the specified index regardless of the current RC
4862 state of the stack. So for example if the stack is split, it will only
4897 stack by pushing it. Conversely on non-RC builds, the count is donated to
4898 the TEMPs stack.
4923 stack. Then for list context, leaves things as is. For void context, the
4924 stack pointer is reset to mark, and everything above is popped. For
4935 but may do so via a wrapper function to adjust the stack as necessary.
4942 manipulate the stack.
4944 rpp_is_lone(sv) indicates whether C<sv>, assumed to be still on the stack,
4949 rpp_stack_is_rc() indicates whether the current stack is currently
4974 pushed, rather than just some sort of I<stack>. push_stackinfo() also has
4975 a boolean argument indicating whether the new argument stack should be