General:
- Add message codes for requesting breakpoint configuration.
UserInterfaceListener/TeamDebugger:
- Add/implement hooks for requesting breakpoint condition changes.
BreakpointsView:
- Add button to request editing the currently selected breakpoint's
condition.
TeamWindow:
- Handle request to show breakpoint edit window.
BreakpointEditWindow:
- Implement simple radio-based UI for modifying the current breakpoint's
condition.
Still missing: Actually handling/evaluating the breakpoint conditions in
the ThreadHandler when the breakpoint is hit.
In order to automate the complete bootstrap build process we need a
mechanism to control the second phase which builds the final packages
on the booted bootstrap Haiku. To avoid additional dependencies
(buildbot slave, ssh, rsh,...) we'd have to cross-build, there's now a
pair of simple python scripts that allows executing commands on a remote
machine. The server script (bootstrap_daemon.py) is added to the
bootstrap image and started automatically during the boot.
CLanguageExpressionEvaluator:
- Add tokenizer handling for operators . and ->.
- Rework _ParseIdentifier() to work recursively if it sees a deref
operator immediately following the current token. This allows
one to refer to the value of structure/class members in an
expression.
* UI still needs some tweaking
* The Services tab has a list of services. This currently include DNS
and will soon also include the services listed in xinetd.
* The DNS tab allows to manage DNS servers (settings can't be saved yet)
- If the current frame belongs to a class function, and the requested name
doesn't match that of any of the parameters/local variables, attempt to
find it in the member list as well.
* Partly reverting hrev47655, as the moved declarations are expected
by many ports to be accessable via string.h.
Following standards is a good thing in general, but not if it causes
more problems than it helps ...
It previously shared the same generated MBR header with bin/writembr,
but they have incompatible needs. The intel partitioning add-on only
wants the MBR code, while writembr wants the whole sector.
Build the desired version of the MBR separately for each target instead
of sharing a single header.
The compile flags were set so that only the boot code itself would be
produced, excluding the (dummy) partition table and signature. The code
in writembr still assumed that the MBR would be 512 bytes however and
therefore access the data array out of bounds.
Fix flags to produce the full 512 byte MBR sector and add a
STATIC_ASSERT so that the size assumption is checked on compilation.
Also fix a typo in mbr.nasm, mostly to trigger re-generation of the
MBR data that one would otherwise need to remove manually...
The two out of bounds array accesses were pointed out by CID 1249923 and
CID 1249924, the insufficiently large target buffer of the memcpy by
CID 1249901.
General:
- Resolving variable values requires both a stack frame and a CPU state.
Adjust all interfaces and callers accordingly.
ExpressionEvaluationJob:
- Pass additional parameters needed for variable value resolution.
- If variable resolution is desired, ExpressionEvaluationJob now
creates a temporary ValueNodeManager for that purpose.
- If the expression parser returns a value node pointer that needs
to be resolved, schedule a corresponding job and wait.
CLanguageExpressionEvaluator:
- Clean up some leftovers that were preventing variable names from being
handled properly in some cases.
- Implement handling of identifier names. These are now looked up against
the value node graph of the active node manager, and if found, corresponding
values are retrieved. If the value has not yet been resolved, an exception
is thrown to ask that to be done.
This gets value resolution working for basic local variables and function
parameters, and consequently, #9712. Structure/class members and/or pointer
indirection aren't yet handled.
With packagefs potentially opening quite a few packages the default of
256 slots is a bit tight. It's 4096 now, which should be safe for a
while, but we might want to consider resizing the table dynamically and
probably even switching to another algorithm for allocating the slots.
Should fix#11328.
- Extend CliContext::Event to be able to store expression
event results.
- Extend CliContext to watch for team expression events and
handle them accordingly.
Factor out message constant for expression evaluation completion,
as multiple places will be using that.
ExpressionEvaluationWindow:
- Check for expression match immediately in listener hook, and
don't bother dispatching to the message loop in such a case.
Simplifies some of the other code.
InspectorWindow / WatchPromptWindow:
- Rather than attempting to evaluate an expression directly,
we now defer to the async interface. Clean up and adjust accordingly.
TeamWindow:
- Adjust window creation calls due to parameter changes.
This leaves only the CLI dump memory command to be adapted.
* VMArea::AddWaiterIfWired(): Replace the ignoreRange argument by a
flags argument and introduce (currently only) flag
IGNORE_WRITE_WIRED_RANGES. If specified, ranges wired for writing
are ignored. Ignoring just a single specified range doesn't cut it
in vm_soft_fault(), and there aren't any other users of that feature.
* vm_soft_fault(): When having to unmap a page of a lower cache, this
page cannot be wired for writing. So we can safely ignore all
writed-wired ranges, instead of just our own. We even have to do that
in case there's another thread that concurrently tries to write-wire
the same page, since otherwise we'd deadlock waiting for each other.
* Remove useless BBox
* Use unicode symbols for play/stop buttons instead of a label
* Since the buttons are smaller, put them on the same line as the file
selector.
As Axel pointed out, B_BAD_DATA is not the correct code here. B_BUSY
could be used but I wantd a code different from the existing one for
"partition already being initialized".
- ExpressionEvaluationWindow now uses the aforementioned
request interface to ask the debugger core to perform evaluation
on its behalf, rather than doing so itself directly.
The remaining users of the expression evaluator will be adjusted in
following commits.
- Add UserInterfaceListener hook to request expression evaluation.
- Add corresponding events/handlers in Team and TeamDebugger.
These allow callers to request evaluation of expressions by the
debugger core's worker threads with asynchronous notifications of
results. While not strictly necessary right now, this paves the way
for further changes to come, as handling of variables will
potentially require resolving their values if they haven't been
already, and this shouldn't be done from user interface threads.
