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,
