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,
Mikhail
--
IMPORTANT NOTICE: The contents of this
email and any attachments are confidential and may also be privileged. If you
are not the intended recipient, please notify the sender immediately and do
not disclose the contents to any other person, use it for any purpose, or
store or copy the information in any medium. Thank you.
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
