Jan Vrany <jan.vrany@fit.cvut.cz> [Tue, 26 Feb 2019 09:27:50 +0000] rev 178
Clean up `GDBVariable(Object) >> #value` and `#valueString`
The distionction was hard to understand, confusing and largelu
unnecessary. This commit removes `#valueString` and leaves only
`#value` with explanatory comment.
Jan Vrany <jan.vrany@fit.cvut.cz> [Mon, 25 Feb 2019 17:55:20 +0000] rev 177
Introduce new internal API `GDBDebuggerObject >> updateFrom:`
to update one ("old") object with another one ("new"). This is used
in cases when we want to preserve an identity of API objects.
Jan Vrany <jan.vrany@fit.cvut.cz> [Mon, 18 Feb 2019 10:49:02 +0000] rev 176
Use `View >> pushEvent:` or `ApplicationModel >> enqueueMessage:` to post events
...rather than asking for a window sensor and then talking to it.
This allows for more flexibility as the object (subscription receiver)
can decide how to handle posting of events.
Jan Vrany <jan.vrany@fit.cvut.cz> [Thu, 07 Feb 2019 15:18:41 +0000] rev 175
Fix for multi-location breakpoints created initially as pending
If the breakpoint has been created as pending breakpoint
it is unknown whether it is a multi-location breakpoint or not
so it has no locations.
If, once the object is loaded abd breakpoint can be installed,
it turns out there are multiple locations, we get an an
=breakpoint-modified event listing all locations.
Therefore, we have to update existing breakpoint and add
locations.
Jan Vrany <jan.vrany@fit.cvut.cz> [Mon, 28 Jan 2019 22:47:57 +0000] rev 174
Add `GDBCLICommand >> #operation` returning (expanded) CLI command
...just like `GDBMICommand >> #operation` returns MI command. This
can be used to test whether user typed in specific CLI command.
However, this method uses static table and this may not be up-to-date
with particular GDB and it is ignorant of any user-defined CLI commands.
Jan Vrany <jan.vrany@fit.cvut.cz> [Mon, 28 Jan 2019 14:56:14 +0000] rev 173
Fix frame of `GDBThreadSelectedEvent` if inferior is running
When ifnferior is running at time we get `=thread-selected` event,
we should at least make that frame kind of usable by fixing up
it's debugger and thread. This allow clients to use (to some extent)
event's frame without worring (too much) about these details.
Jan Vrany <jan.vrany@fit.cvut.cz> [Thu, 24 Jan 2019 21:59:23 +0000] rev 172
Update target features from `=target-connected event`
...so feature list is up-to-date
Jan Vrany <jan.vrany@fit.cvut.cz> [Wed, 23 Jan 2019 22:20:29 +0000] rev 171
Fix DNU in `GDBMITraceViewer` when debugger terminates
Jan Vrany <jan.vrany@fit.cvut.cz> [Wed, 23 Jan 2019 21:38:06 +0000] rev 170
Add `GDBDebugger >> #waitForAllEventsProcessed` and `#waitForAllCommandsProcessed`
These methods are meant mainly for synchronization in tests, NOT
for normal user code. Uses should avoid calling these.
Jan Vrany <jan.vrany@fit.cvut.cz> [Sat, 19 Jan 2019 23:25:55 +0000] rev 169
API: add `GDBDebugger >> getParameter:` and `setParameter:to:`
...to get / set GDB internal parameters such as prompt. The only
complication here is that when a parameter is set by MI `-gdb-set`
command, the `=cmd-param-changed' notification is not sent. This
may or may not be a GDB bug.
To make this transparent to `libgdbs` clients, intercept all `-gdb-set`
commands and when sucessful, emit the event manually. This way, client
may rely on value change notification (`GDBCmdParamChangedEvent`) to
detect changes.