History log of /haiku/src/apps/debugger/user_interface/cli/CliContext.cpp
Revision Date Author Comments
# 7bdeef54 09-Dec-2016 Rene Gollent <rene@gollent.com>

Debugger: Rework parts of report generation.

Team:
- Adjust report generation event to include a final status code for listeners.

CliContext,TeamWindow,ReportUserinterface:
- Use aforementioned status code to indicate whether report generation
succeeded or failed.

DebugReportGenerator:
- Notify listeners if report generation fails. This may have previously
been responsible for some bug reports where it was indicated that the
debugger hung without exiting after being asked to save a report from
a crashed app.
- When dumping disassembly, retrieve it directly if necessary rather than
requesting it via the user interface listener. This also fixes the quirk
that requesting to save a crash report while looking at the source code
of a function would trigger switching it to disassembly visually.
- When walking the list of threads to dump, acquire references to all of
them before starting. Otherwise, it was potentially possible for a running
but not crashed thread to exit while we were generating the report, leaving
us with a pointer to a deleted thread. This was most likely the cause of one
of the crashes reported in #13082.
- When receiving the notification that source code state has changed, clear
the waiting function. Otherwise, it was potentially possible for us to get
other state change notifications, leading to the data semaphore being
released too often. This would then cause later potential waits such as
the stack frame memory dump to not actually wait when they should,
potentially leading them to dereference objects that weren't yet ready.
This fixes another of the crashes in #13802.


# e2d845a4 26-Apr-2016 Rene Gollent <rene@gollent.com>

Debugger: Implement remainder of #12729.

UserInterfaceListener:
- Add request hook for writing a core file. Implement in TeamDebugger.

Jobs/WriteCoreFileJob:
- Add new job to actually dispatch the core file request via the debugger
interface.

Team{::Listener}
- Add listener event + hook for notifications when a core file gets written.
Implement in CLI.

CliContext:
- Add event flag for core file changed.

CommandLineUserInterface:
- Add 'write-core' command. This optionally takes a path to write the core to,
otherwise one is automatically generated by, similarly to debug reports. As
such, one can now generate cores for things like app_server and registrar
crashes if desired, in addition to reports.


# 2d9d01e2 21-Aug-2015 Rene Gollent <rene@gollent.com>

Debugger: Refactor non-interactive report handling.

- Add dedicated ReportDebugger application class for the case where we're
asked to do nothing more than save a report. Also add a corresponding
UserInterface subclass whose sole purpose is to take those necessary
actions and then exit.
- When the debugger is invoked via the --save-report option, we now start
via the aforementioned report/interface rather than piggybacking on the
CLI.
- Clean up CommandLineUserInterface/CliContext to remove handling for the
report saving option.

Should hopefully resolve #12155.


# 81c848a1 14-Nov-2014 Rene Gollent <rene@gollent.com>

Debugger: Rework expression parsing API.

ExpressionInfo:
- No longer stores an explicit result type (this is inferred from
evaluation of the expression itself now).
- Introduce class ExpressionResult for returning the result of an
expression computation. This can currently take the form of either
a primitive value, or a value node object.
- Adjust UserInterfaceListener and ExpressionInfo::Listener to take
the above changes into account, and correspondingly adjust all
callers/listeners.

CLanguageExpressionEvaluator:
- Introduce child class Operand. This subsumes the functionality that
was previously in the separate Number class, and can represent a
primitive value, a value node or a type. Also has functionality to
implicity handle type promotion/inferring when performing calculations
between operands.
- Adjust expression parser to operate in terms of Operands rather than
Numbers. This allows a number of improvements, most notably that an
expression can now return a value node as a result rather than only
a primitive number. This capability isn't yet fully used, but paves
the way for future uses such as an expression that evaluates to a data
member, a global variable, or an arbitrary pointer of a particular type.
- Various cleanups/simplifications that were possible as a result of the above
changes.

ExpressionEvaluationWindow/ExpressionPromptWindow:
- Remove type menu field, since the expression API no longer uses it.

Adding/removing expressions in the VariablesView is temporarily disabled,
pending some further rework there to properly handle the new result object.


# d1c9ffed 08-Nov-2014 Rene Gollent <rene@gollent.com>

Debugger: Cleanup.

Team:
- Remove expression evaluation event / listener hook. This doesn't
really belong to the Team anyways.

UserInterfaceListener:
- ExpressionEvaluationRequested() now takes an ExpressionInfo object
rather than the individual subcomponents.

ExpressionEvaluationJob:
- Notification of expression evaluation completion is now handled
via the info object's listener interface rather than the Team.

Others:
- Adjust all users of expressions to set themselves up as
ExpressionInfo::Listener subclasses, and consequently add themselves
to the respective info object when requesting evaluation. This
significantly simplifies various things, and also ensures that no
one accidentally gets notified of an expression they didn't actually
ask for, which could occur with the previous Team-based listener
interface. Make all other required adjustments for new interface
usage.

No functional change intended.


# 8b9099b1 04-Nov-2014 Rene Gollent <rene@gollent.com>

Debugger: Fix #11411.

CliContext/CommandLineUserInterface:
- Process the debug report event asynchronously. The missing lock that
was fixed in commit 5ac34e5a78305abac4c758a34db9f1e34aee54ed highlighted
a problem in how the CLI was handling the case where it was intended to
exit immediately after saving a report, since it issued the quit request
directly from the report event handler. This resulted in locking issues,
as the team debugger would then attempt to tear itself down, during which
it needs to acquire the team lock. However, that was already being held
by the thread in which the CLI was initiating the quit, resulting in a
deadlock.


# 38258751 29-Oct-2014 Rene Gollent <rene@gollent.com>

Debugger: Add expression support to CliContext.

- Extend CliContext::Event to be able to store expression
event results.
- Extend CliContext to watch for team expression events and
handle them accordingly.


# c7f5dd62 18-Dec-2012 Rene Gollent <anevilyak@gmail.com>

Add support for memory block events to CliContext.


# 03289a33 18-Dec-2012 Rene Gollent <anevilyak@gmail.com>

More adjustments to CliContext.

- CliContext now listens for value node container events so that
commands can request such a wait as well
- Implement an event wait mechanism for commands to make use of.
Adjust CliStackTrace and CliPrintVariable accordingly.


# 1325ad5f 16-Dec-2012 Rene Gollent <anevilyak@gmail.com>

Various improvements to CliContext.

- CliContext now tracks the current stack trace and frame if applicable.

- CliContext now carries a value node manager. This allows it to track
the variables in the currently active frame.


# 86b1039b 04-Aug-2012 Ingo Weinhold <ingo_weinhold@gmx.de>

Debugger CliContext: More event handling, current thread

* Introduce the notion of a current thread. That's the one certain
commands will target (by default).
* Add more event handling in CliContext. There's now a queue of pending
events which are printed in the input loop at convenient times to
inform the user about what happened (new/deleted/stopped threads,
etc.).


# d266c87d 28-Jul-2012 Ingo Weinhold <ingo_weinhold@gmx.de>

Debugger: CliContext: Introduce the notion of events

* The input loop can now wait on abstract events, which other threads
(or even the input loop thread itself) can signal.
* Use the new mechanism in QuitSession().
* Also (with the exception of the SIGINT part) implement
WaitForThreadOrUser().


# 8fe9f8b2 27-Jul-2012 Ingo Weinhold <ingo_weinhold@gmx.de>

Debugger CLI: Move more stuff to and extend CliContext

* Move the libedit interface there and provide nicer to use methods.
* Also start adding utility methods for the input loop. It is going to
manage all interactions of the input loop with outside events.
* Fix the "quit" command. The user is now prompted what to do with the
debugged team and the input loop thread avoids reentering the input
loop.


# d0ef7540 23-Jul-2012 Ingo Weinhold <ingo_weinhold@gmx.de>

Debugger CLI: Start to imbue CliContext with life


# 2d9d01e2e849737a184f83779311a04346a5be98 21-Aug-2015 Rene Gollent <rene@gollent.com>

Debugger: Refactor non-interactive report handling.

- Add dedicated ReportDebugger application class for the case where we're
asked to do nothing more than save a report. Also add a corresponding
UserInterface subclass whose sole purpose is to take those necessary
actions and then exit.
- When the debugger is invoked via the --save-report option, we now start
via the aforementioned report/interface rather than piggybacking on the
CLI.
- Clean up CommandLineUserInterface/CliContext to remove handling for the
report saving option.

Should hopefully resolve #12155.


# 81c848a14a380679a439cccb9e10b60d05bd6fbc 14-Nov-2014 Rene Gollent <rene@gollent.com>

Debugger: Rework expression parsing API.

ExpressionInfo:
- No longer stores an explicit result type (this is inferred from
evaluation of the expression itself now).
- Introduce class ExpressionResult for returning the result of an
expression computation. This can currently take the form of either
a primitive value, or a value node object.
- Adjust UserInterfaceListener and ExpressionInfo::Listener to take
the above changes into account, and correspondingly adjust all
callers/listeners.

CLanguageExpressionEvaluator:
- Introduce child class Operand. This subsumes the functionality that
was previously in the separate Number class, and can represent a
primitive value, a value node or a type. Also has functionality to
implicity handle type promotion/inferring when performing calculations
between operands.
- Adjust expression parser to operate in terms of Operands rather than
Numbers. This allows a number of improvements, most notably that an
expression can now return a value node as a result rather than only
a primitive number. This capability isn't yet fully used, but paves
the way for future uses such as an expression that evaluates to a data
member, a global variable, or an arbitrary pointer of a particular type.
- Various cleanups/simplifications that were possible as a result of the above
changes.

ExpressionEvaluationWindow/ExpressionPromptWindow:
- Remove type menu field, since the expression API no longer uses it.

Adding/removing expressions in the VariablesView is temporarily disabled,
pending some further rework there to properly handle the new result object.


# d1c9ffed344208f126f1b8fd446347556c03e976 08-Nov-2014 Rene Gollent <rene@gollent.com>

Debugger: Cleanup.

Team:
- Remove expression evaluation event / listener hook. This doesn't
really belong to the Team anyways.

UserInterfaceListener:
- ExpressionEvaluationRequested() now takes an ExpressionInfo object
rather than the individual subcomponents.

ExpressionEvaluationJob:
- Notification of expression evaluation completion is now handled
via the info object's listener interface rather than the Team.

Others:
- Adjust all users of expressions to set themselves up as
ExpressionInfo::Listener subclasses, and consequently add themselves
to the respective info object when requesting evaluation. This
significantly simplifies various things, and also ensures that no
one accidentally gets notified of an expression they didn't actually
ask for, which could occur with the previous Team-based listener
interface. Make all other required adjustments for new interface
usage.

No functional change intended.


# 8b9099b1b24358076e28f6e3a894e6f39de4cece 04-Nov-2014 Rene Gollent <rene@gollent.com>

Debugger: Fix #11411.

CliContext/CommandLineUserInterface:
- Process the debug report event asynchronously. The missing lock that
was fixed in commit 5ac34e5a78305abac4c758a34db9f1e34aee54ed highlighted
a problem in how the CLI was handling the case where it was intended to
exit immediately after saving a report, since it issued the quit request
directly from the report event handler. This resulted in locking issues,
as the team debugger would then attempt to tear itself down, during which
it needs to acquire the team lock. However, that was already being held
by the thread in which the CLI was initiating the quit, resulting in a
deadlock.


# 382587517f78fe14f3dda421bced6a462949f1ec 29-Oct-2014 Rene Gollent <rene@gollent.com>

Debugger: Add expression support to CliContext.

- Extend CliContext::Event to be able to store expression
event results.
- Extend CliContext to watch for team expression events and
handle them accordingly.


# c7f5dd6207ea0c29c149067fe5f46cb95fd3e576 18-Dec-2012 Rene Gollent <anevilyak@gmail.com>

Add support for memory block events to CliContext.


# 03289a339ceabd34eb4f909f13585a780ac4bef2 18-Dec-2012 Rene Gollent <anevilyak@gmail.com>

More adjustments to CliContext.

- CliContext now listens for value node container events so that
commands can request such a wait as well
- Implement an event wait mechanism for commands to make use of.
Adjust CliStackTrace and CliPrintVariable accordingly.


# 1325ad5fe84c9aa5e3300eeef5098cb89d0b7e72 16-Dec-2012 Rene Gollent <anevilyak@gmail.com>

Various improvements to CliContext.

- CliContext now tracks the current stack trace and frame if applicable.

- CliContext now carries a value node manager. This allows it to track
the variables in the currently active frame.


# 86b1039b4240746ffe42bd8563b5333751bd2456 04-Aug-2012 Ingo Weinhold <ingo_weinhold@gmx.de>

Debugger CliContext: More event handling, current thread

* Introduce the notion of a current thread. That's the one certain
commands will target (by default).
* Add more event handling in CliContext. There's now a queue of pending
events which are printed in the input loop at convenient times to
inform the user about what happened (new/deleted/stopped threads,
etc.).


# d266c87d174fc714e2c0ecbfe9c18713f3c9215d 28-Jul-2012 Ingo Weinhold <ingo_weinhold@gmx.de>

Debugger: CliContext: Introduce the notion of events

* The input loop can now wait on abstract events, which other threads
(or even the input loop thread itself) can signal.
* Use the new mechanism in QuitSession().
* Also (with the exception of the SIGINT part) implement
WaitForThreadOrUser().


# 8fe9f8b2d0e3c8f88406f5720a1d2027638c43b6 27-Jul-2012 Ingo Weinhold <ingo_weinhold@gmx.de>

Debugger CLI: Move more stuff to and extend CliContext

* Move the libedit interface there and provide nicer to use methods.
* Also start adding utility methods for the input loop. It is going to
manage all interactions of the input loop with outside events.
* Fix the "quit" command. The user is now prompted what to do with the
debugged team and the input loop thread avoids reentering the input
loop.


# d0ef75400b4136bac523bb2f71cd55af2262543a 23-Jul-2012 Ingo Weinhold <ingo_weinhold@gmx.de>

Debugger CLI: Start to imbue CliContext with life