The post syscall debug events used for output capture have an
unfortunate side effect: when asked to debug a thread, the thread is
interrupted, which, if currently blocked in a syscall will cause it to
unblock and send a post syscall event indicating such. However, this
will also absorb the debug stop flag that was set by the initial debug
request, and so we won't actually get the separate event indicating
thread debugged.
Consequently, we now set a pending stop request flag on the
corresponding Thread object, and check if it's set when processing
syscall events. If so, we treat such an event as having triggered a
debug stop even though the received event type is not explicitly
B_DEBUGGER_MESSAGE_THREAD_DEBUGGED.
- The argument buffer contained in the debug_{pre,post}_syscall message structures wasn't large enough to accomodate all
arguments for some syscalls on x86-64, which could potentially have led to kernel memory corruption when using syscall
tracing via the debug API. As such, enlarge it to accomodate 64-bit platforms as well.
- Adjust TeamDebugger/SyscallInfo to discriminate the target architecture and read the arguments when trapping console
output. Gets the latter working on x86-64.
We now watch for file write syscalls in the target team. If they
constitute a write to either stdout or stderr, we attempt to capture the
output, and notify interested listeners accordingly.
- In the case where retrieval of a memory block failed, InspectorWindow
didn't handle the notification. Consequently, it never removed itself as
a listener from the failed block, nor did it release its reference for
it. Consequently, if one attempted to retrieve data from the same block
again, walking the listener list would crash due to the already-deleted
entry in the list.
- The success case had the same problem with regards to not removing its
listener, but was masked by virtue of the inspector currently being the
only user of the memory block manager, so in the latter case the blocks
would be properly released/destroyed and the aforementioned walk would
never occur.
- Adjust locking a bit to ensure that manipulating the listener list
always happens with the team lock held.
- Style fixes.
Now takes an optional boolean parameter to indicate that disassembly is
explicitly being requested. Adjust TeamDebugger and LoadSourceCodeJob's
implementations accordingly.
- TeamDebugger's listener interface now exports a
TeamDebuggerRestartRequested hook. The latter is used to request
starting a new debugger instance with the same arguments/settings as the
team it represented. Implemented for the graphical debugger.
- When a team terminates, the resulting dialog now allows the user to
choose to quit, restart, or simply do nothing. The latter option still
needs some work though, as e.g. setting additional breakpoints currently
fails since the corresponding debugger interface is no longer around.
Implements the main part of #9774.
- UserInterfaceListener/TeamDebugger: Extend ThreadActionRequested()
to allow passing a target address. Adjust TeamDebugger's
implementation accordingly.
- ThreadHandler: The MSG_THREAD_RUN action can now optionally take an
address parameter to run until. If this is specified, set a temporary
breakpoint for said address before resuming execution.
- SourceView: On right click, present a context menu showing possible
actions for the current line if we're currently in a stopped thread.
For the moment, this only yields the "Run to cursor" action, but
more will be added in the future.
- Instead of asking nodes to resolve themselves directly,
DebugReportGenerator now uses the interface listener to ask the
debugger's workers to resolve them on its behalf.
- When an image creation notification is received, the thread
that provoked it needs to be suspended until the debugger has
finished loading the image's debug information. Otherwise, if that
image had a breakpoint in it, it was possible that the thread would
execute past the code where the breakpoint should be before the
debugger had a chance to actually install it.
- Only update breakpoints when debug info loading has actually finished.
- DebugReportGenerator is now its own BLooper that generates reports asynchronously
instead of in TeamDebugger's message loop.
- If a stack trace isn't yet available, DebugReportGenerator now waits for it to
be generated.
- Extended Team to add a listener event for report generation completing. DebugReportGenerator
now generates such an event when it has finished writing a report.
Rene Gollent