The documentation and help for the set command was pretty useless. Made it convey what is possible. Also added and option for the maximum length allowed by the = command. Increased the print level from 3 to 5 since 3 seems too small for real life debugging examples.
Differential Revision: D953805
The set command can alter the values of some of the settings that are kept in the per user debugger configuration file. However, these settings do not get persisted back into the configuration file. Since the configuration file is affected by other user commands, this seems a tad strange. As we add more user options, I suspect that these options will be more discoverable if they are documented as part of the set command and if they persist in the configuration file.
Differential Revision: D952387
The code to print out the result of the expression following the = command has moved from inside the resulting eval block, to outside it in the debugger code itself. Hence, if the eval block fails, the value of $_ now prints out and this is confusion because it is the value that a previous = command put in there. With this change the eval block first unsets $_, so that the subsequent print value code will do nothing in the case of a failure.
Differential Revision: D944120
The C++ vtable pointers and the m_cls pointers in ObjectData are
redundant for C++ extension classes; they both indicate the ObjectData's
dynamic type.
This diff gives ObjectData the same treatment that the ArrayData
hierarchy got, replacing virtual functions with manual dispatch based on
attributes and m_cls. We can't do direct comparison against m_cls,
because of inheritance, except when we know inheritance is not in the
picture.
The vtable isn't gone yet, because I need to do something about C++
destructors, which still require virtual dispatch. That's going to
require a lot of grunt work, so I wanted to put this diff up to keep
that stuff separate.
I did, however, make ~ObjectData non-virtual and try to compile, to
flush out all the dynamic_casts of ObjectData.
- The type-casting functions and clone() are pretty straightforward. The
only trick is that specialized clone() functions now have to call
cloneImpl() instead of the base class' clone(), otherwise infinite
recursion. I added an ObjectData attribute to indicate whether clone()
is special.
- t___{sleep,wakeup} didn't even need to be virtual, it turns out.
ObjectData's implementation goes through the normal PHP-method lookup
path, which effectively does virtual dispatch and routes us to any
specialized implementations anyway.
Differential Revision: D940852
The = command has recently been changed to use standard debugger serialization rather than to invoke a customizable function, or print_r otherwise. In the process a bug crept in that made the output not colored. This fixes that bug. It also updates the help text to make it clearer that = truncates text. While looking at that I noticed that the help text for the print command suggested that it's output is formatted with print_r. Fixed the text as well, but while I was at it introduced the "print r" flag to make it possible to invoke print_r, analogously to the already existing "print v" command. While adding test cases, I noticed that the truncation logic appears to be broken, so I fixed that as well.
Differential Revision: D931565
Add source file and line to async functions on the debugger async stack. This information is only added for async functions which are not actually being executed. Those exist on the normal stack, and their location information is visible there. The location added for async functions which are not running is that of the yield which has caused the continuation to pause.
Differential Revision: D930103
Expose the async stack in the debugger. This is the stack of, say, generators driven from the ASIO extension. This is a modification to the where command. The new command type accounts for back compat between old servers/clients. I've added a shortcut, "wa", which is a bit faster to type.
I also modified the normal stack trace to not print bogus lines for functions with no file/line info.
Differential Revision: D920910
This replaces ArrayInit's vectorInit constructor. When we
know we're making a vector-shaped array, there's no need to
internally use the general array api; ArrayInit provides the
api, internally we do what's fastest.
Differential Revision: D903252
The PHPUnit test suite calls get_defined_constants(true), for categorization. We threw. Now we don't. Now we actually do something sort of correct, but not fully correct. We have a "user" and "core" constant categorization. Function cleanup and consolidation. That's good. But Zend categorizes even more into extensions. This is a first step. And two (2) tests now move from zend/bad to zend/good.
Differential Revision: D909942
Breakpoints correspond to source lines, not byte code operations, so more than one operation may correspond to a break point. Each operation checks for breakpoints, so breakpoints are disabled when encountered, otherwise commands such as continue and next would get stuck on a line until all the byte code operation for a line have been carried out. Such break points are re-enabled as soon as a byte code for another line is executed. This does not work if no other byte codes are carried out (i.e. if JITted code runs) until control loops back to the disabled break point. Consequently the disable logic now keeps track of the offset of the byte that first triggered disablement. If the break point is still disabled by the time control comes back to that byte code, the break point is temporarily enabled.
Differential Revision: D909092
The debugger's API mode added a lot of extra complexity to the debugger client for minimal value. It also had a bunch of bugs, and unnecessarily tied alternate debugger clients to the command line client implementation. Deleting it.
Differential Revision: D912729
Request Start has no activation record on the stack, but Next is quite valid and should still work. Modified to tollerate the lack of act rec.
Differential Revision: D908499
In HHVM we've been piggybacking resources on the KindOfObject machinery.
At the language level, resource is considered to be a different type than
object, and there are a number of differences in behavior between objects
and resources (ex. resources don't allow for dynamic properties, resources
don't work with the clone operator, the "(object)" cast behaves differently
for resources vs. objects, etc).
Piggybacking resources on the KindOfObject machinery has some downsides.
Code that deals with KindOfObject values often needs to check if the value
is a resource and go down a different code path. This makes things harder
to maintain and harder to keep parity with Zend. Also, these extra branches
hurt performance a little, and they make it harder for the JIT to do a good
job in some cases when its generating machine code that operates on objects.
This diff introduces a new DataType called "KindOfResource", it separates
ResourceData from ObjectData's inheritance hierarchy, introduces a new
smart pointer types called "Resource" and "SmartResource", updates the
runtime as appropriate, and kills some more dead code in ObjectData and
ResourceData. I've tried to keep behavior the same for the most part and
resisted the urge to fix existing bugs with resources.
The = command uses formatting that is user customizable and subtly different, by default, from the formatting used by the print command and the variable command. This has historical roots. It seems that the debugger used to use print_r, which is brittle, and the customization hook was introduced to work around this brittleness. This work around is no longer necessary since the debugger now has its own, robust way of formatting values as strings. Also, the difference between = and print is a perennial source of confusion for debugger users.
Dumps information about allocation events in smart
allocator, and aggregates some information such as bytes
allocated per callsite in the current request (or across
requests). This information can be gathered in the heaptrace
command, and the information collected during the trace is
enough to find how much memory an object is responsible for
(i.e. keeping reachable).
It's all conditionally compiled because perflab showed a pretty
significant instruction regression if it was a runtime option.
You'll need to fbconfig with --extra-cxxflags=-DMEMORY_PROFILING
in order to use it.
This isn't done, but I wanted to get some feedback on where I
should take this (general design, what to log, where to dump
stuff, etc)
A real breakpoint makes entries in the breakpoint filter for all offsets at the given line. Various flow control commands will also use the breakpoint filter to add and remove temporary "internal breakpoints" required during the flow operation. Ensure that we never remove a breakpoint filter entry if there was already one there due to a breakpoint (or really any other reason).
No emitted bytecode relies on Continuation being stored in local 0
anymore. Stop using local 0 for this purpose and compute offset
to the Continuation at JIT time. 16 bytes of memory freed.
At this point all locals of Continuation construction wrapper share the
same indices with their respective locals of Continuation body, which
should allow further optimizations.
Flow control commands should not evaluate the conditions of conditional breakpoints when enabling and disabling breakpoints during stepping. Also, all breakpoints, rather than just the first matching breakpoint should be enabled/disabled.
There was a race in the debugger protocol tests which send bad commands to the proxy and expect it to disconnect. If the proxy thread was fast enough it would mark the client as stopped, and we'd skip trying to get a new message after sending the bad command. This means missing one line of output in very rare cases. I've put in a wait to ensure that the client settles in the stopped state before continuing, to remove the race.
A client couldn't break execution during eval. There used to be a lot of barriers to making that right, but I fixed most of them with a previous diff on unifying client-side event loops. Now the only barrier was that a server-side thread processing an interrupt was blocking the signal polling thread by holding a mutex while processing the interrupt. Changed to set a flag to disable polling when starting to process the interrupt (and unsetting it when done), while still synchronizing with the signal polling thread to ensure only one thread is sending the client messages at a time. Added logic to re-enable polling while executing PHP for eval, print, etc. Plumbed the proxy thru to the point where we check the clause on conditional breakpoints, too, since that's the third (and final) place we do this.
break start/end/psp currently always report themselves as unbound. If the client is connected to a sanbox, these should instead be treated as bound. Also, break clear all currently removes breakpoints without running their destructors in the right order, which causes the break point counter to not reset to 1.
In HHVM (and HPHPc before it) we've been piggybacking resources on the
KindOfObject machinery. At the language level, resource is considered to
be a different type than object, and there are a number of differences
in behavior between objects and resources (ex. resources don't allow for
dynamic properties, resources don't work with the clone operator, the
"(object)" cast behaves differently for resources vs. objects, etc).
Piggybacking resources on the KindOfObject machinery has some downsides.
Code that deals with KindOfObject values often needs to check if the value
is a resource and go down a different code path. This makes things harder
to maintain and harder to keep parity with Zend. Also, these extra branches
hurt performance a little, and they make it harder for the JIT to do a good
job in some cases when its generating machine code that operates on objects.
This diff prepares the code base for a new KindOfResource type by adding a
new "Resource" smart pointer type (currently a typedef for the Object smart
pointer type) and it updates the C++ code and the idl files appropriately.
This diff is essentially a cosmetic change and should not impact run time
behavior. In the next diff (part 2) we'll actually add a new KindOfResource
type, detach ResourceData from the ObjectData inheritence hierarchy, and
provide a real implementation for the Resource smart pointer type (instead
of just aliasing the Object smart pointer type).
This abstracts the file format a bit, so that we can
dump to multiple formats. Currently, GraphViz and GML are
supported. GML was added at @edwinsmith's request (and it's much
nicer than GraphViz anyway...)
Adds an extension command to the debugger which provides
heap tracing functionality, and adds the framework needed to get
heap traces. The heaptrace command can dump the current heap to the
debugger session or it can save a GraphViz specification to a file.
I'm hoping to add a backend which can put the graph in GML format,
so it can be explored interactively. I also hope at some point to
see this integrated into FBIDE if we can do that.
Added some test cases. Also now permit caller=>func() type of breakpoints. To make this work, I added a method, getCallingSite, to class InterruptSite and use this to walk the stack when checking if a site matches a break point that has more than one function name.
Updates continuations to allow yielding of a key-value
pair from a generator. Adds bytecode instructions (PackContK,
ContKey) for using the new feature, and adds IR instructions
(ContUpdateIdx, ContIncKey) to help get it down to the metal
(in particular, ContIncKey attempts to keep the current use-cases
as fast as possible).
PackCont opcode is always followed by ContExit so let's join them into ContSuspend. ContResume counterpart may come later (replacing ContNext/Send/Raise/Enter).
The [z]end command in hphpd runs the last manually entered snippet of php in "zend". If you typed 'z' before actually entering any php, it would segfault. Fixed a minor bug in Process::Exec, and present help if none entered. Also clarified that it will simply use your system's default php, and made it so you can override which exe to use with a hphpd config variable. The default is "php", since that is most commonly used.
Add a bit more usage logging for the debugger, and ensure that there is a common field between clients and servers thats easy to search on, i.e., sandbox id.
Because stronger types are better types, and this will make
future refactoring easier. I considered trying to purge the Opcode
type from the codebase too but that would be a much bigger project.
C++11 cleanup (clean up easy enums)
This is for runtime/base/... and ended up touching a lot of files
because it turns out we have a lot of reasonably behaved enums.
Paul Bissonnette