Perhaps a more intuitive approach in this scheme would be to have the "open
disassembly" button on the toolbar and have the sub-menu "stepping mode" action
on the context menu.
Agree, I'll do it.
Hi Pawel,
Sorry for the late response - I was attending
a meeting and surprisingly had no internet access at
all.
Regarding the instruction stepping mode
action, I am just proposing to extend the existing feature in
CDT. In my implementation the action is visible only when a certain
interface is exposed. We can make it model dependant so you can use
your own action instead and do whatever you want. Is this a better option for
you?
I agree that a preference to open disassembly
automatically is required if the source information is not available or the
source file is not found. I had the "Always/Never/Prompt" preference
in my original implementation, but removed it because the prompt was very
annoying and the "source not found" editor had "Open Disassembly" action
anyway.
I guess, I should add "Open disassembly
automatically" preference instead.
Thanks for your
feedback,
Mikhail
In my experience what
works best is to link the choice to use the disassembly viewer to the
instruction stepping mode and not the other way around. I.e. if the user
chooses to perform instruction stepping, the disassembly editor is opened
automatically. What helps the user also is to have context actions in
the editor and disassembly which allow user to jump to the other (and
automatically switch the stepping mode).
As an override, the Wind
River debugger has a preference to always open the disassembly viewer whether
or not instruction stepping is turned on, although I think very few users even
know about this.
A second option which makes disassembly more useful
is an option in the source-not-found editor, to always open disassembly.
In the Wind River debugger this is implemented using a source container,
although I'm not sure about the wisdom of this because the disassembly
container does not really perform any lookup. It might be better to
implement it using a dedicated flag in the source lookup
director.
Mikhail Khodjaiants wrote:
1. Management of disassembly/source
editors and source lookup
The
only way to open a disassembly editor window is to use the "Open
Disassembly" action from the Debug view's context menu or from the
"Source Not Found" editor.
Once the disassembly editor is opened for a
disassembly context it becomes the default editor for all elements
that expose the same debug context.
There
are two options on how to manage the source editors in this
case:
a.
always try to open the source editor in background if the source file is
available
b. do
not try to open the source editor. In this case to open it user has to close
the disassembly editor and double click on the corresponding stack
frame.
In
both cases we need to maintain the IP position in the source editor if
it is open, which means that we can not use the default ISourceDisplay
adapter provided by the platform :(
IMO
opening both disassembly and the editor seems like an overkill. It may
even be rather confusing to the user as well. It may also be confusing
to the user to keep the existing disassembly view as a view. Perhaps it
would be better to replace the disassembly view with a memory
rendering.
Cheers,
Pawel
2.
Stepping mode selection
Currently there is a toggle action
"Instruction Mode" to switch between the source and instruction modes. There
have been requests to make the instruction mode default when the disassembly
view has focus (doesn't seem to work
anymore).
I
would propose to replace the "Instruction Mode" action by
the dropdown menu with the following
choices:
a.
"Context" - use the instruction mode if the disassembly window is
open, otherwise use the source mode
b.
"Source" - always use the source mode.
c.
"Instruction" - always use the instruction
mode
3.
Preference pages
As
the content of the disassembly viewer is provided by models the
creation of preference pages becomes a problem. It seems that we need one
global page for the preferences shared by all models and a special
preference page for each model. It could be confusing for the end
users.
4.
CDI support
Currently, the CDI interfaces for disassembly are
duplicates of the disassembly related gdb/mi commands. This
is not sufficient to implement the efficient "infinite" scrolling
which is a big challenge for assemblers
with variable instruction size.
Does
it make sense to add an API extensions for
the cases when some additional
information (like previous/next valid instruction address) is available from
the backend?
Comments? Ideas?
Thanks,