stack values are distinct from loclist results
return value from DW_OP_ function simplified and name field moved to
loclistOperator type
added support for DW_OP_piece
added a small delay to the program after SDL SetFullscreen() has been
called. this seems to give the system time to make the change to the
full screen state - meaning that placement of imgui windows in the
debugger is more consistent
executable lines annotated with an inline symbol in an inlined function,
instead of the chip symbol
dropped the idea where we yield all function variables regardless of
scope. it didn't play with how inlined functions work. will think about
how to implement the idea better
until the source window has been updated to indicate breakpoints/executable
lines better, the emulation will continue to allow breakpoints on any
executable line
variable location rule(s) taken from abstract variable entry as appropriate
changed breakpoint symbol
ReloadCartridge() and InsertCartridge() didn't interact with the input
loop very well. this meant that if those functions were called when
execution was deep inside the input loop (during execution of the ARM
program, for example) the emulator could crash
fixed by wrapping the functions in a loop unwinder (same mecahnism as
for rewind handling)
sometimes a function can contain more than variable with the same name
in different scopes. the list of locals now only include one entry for
each name
cleanup of code behind the "focus yield line" button in the source window
we tried to avoid having to update variables from a non-emulation
goroutine but this turns out to have major performance impact
reverts many of the changes in 9c434f477
previously, the first address in the list of address for a line of
source was used. however, this was poor because the first address in a
loop for example, is probably never called again even when the loop
iterates
this method should also naturally lend itself to single stepping through
the source (not yet implemented)
previous filter didn't take into account many factors, including: the
possibility of multiple local variables with the same name; iterating
over a map is random so the results seen were unpredictable
corrected address range field for SourceFunction. the address range
referred to the declaration line only. this wasn't actually used for
anything meaningful so the error wasn't noticed. but we do want to use
it in order to help locate local variables
if any instuction associated with the source line that the PC address is
associated with is within range of a variable then the variable is
considered to in scope and will be displayed in the local variables
window
only local variables that are stored in registers are handled at the
moment but that's good enough to show the basic breakpoint mechanism
works
sketched in local variables window
addresses/values are retreived from memory dynamically. this is
preparatory work for local variable support
coproc globals window vastly simplified as a result of these changes
horizontal bar always shown if window is small enough for at least one
line in the file
horizontal scrolling for source window
line selection works better and more consistently
disasm tooltip does not flicker during line selection
list of short filenames sorted (coprocessor source files)
if a left mouse button is pressed down and up in the same frame, imgui
will not see the down event. trickling the two events over two frames
should solve the problem
more careful enabling/disabling of cartridge breakpoint. we don't want
them triggering during rewinding or during startup, for example
transition from playmode to the debugger when a breakpoint is triggered,
works better - still not perfect though
if yield line is invalid then it focuses on the "main" function as
before
this is useful for situations where the program runs into a problem
immediately on initialisation
if a DWARF was built on another machine it is likely that the path the
source code is wrong. the DWARF can be loaded and would be useful but
without source information to back it up
an additional nil check in the source window resolves that
changed (simplified) behaviour of fuzzyFilter (renamed from
fuzzyMatcher) so that it is drawn as a complete unit, as opposed to a
text input widget and a separate selection list
UI is rudimentary for now and of course, there is no local variable
inspection
implemented for CDF and ACE only for now. DPC+ will use the same
technique as CDF once it's been finalised and ELF will be similar to ACE
<entry> wasn't really a good name for what was happening. any
instructions that are outside of the ROM are executed or otherwise
handled in the driver, represented by the emulation
this works well for ELF in particular in which StrongArm ROMs make
heavy use of the driver
