[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [dsdp-dd-dev] Disassembly proposals
|
Hi James,
Viewing a binary file as disassembly is relatively simple
task comparing with the requirements we have for the disassembly tied to a debug
session. The latter requires access to the target memory. For slow targets it is
very costly that's why our goals are:
1. divide the rendering process into a group of
independent tasks and run most of the time consuming tasks in non-UI
threads.
2. minimize the amount of data required from the target.
For instance, only the visible part of the disassembly window is
updated.
Correct me if I am wrong but for binary files
these limitations are not required. A regular editor mechanism can be used
to view it nothing more.
The other requirement is to make the disassembly viewer
flexible, so it can accommodate various debug models. The third parties will be
able to overwrite the content by registering special adapters, like the
content adapter that is responsible for the content retrieval, the label adapter
to render lines in the view and the annotation adapter to manage the annotations
(instruction pointers, breakpoints, etc). It is almost working with our debugger
which is not gdb based and in a couple of days I'll post the viewer
proposals.
> Is there any
reason not to have the disassembly view 'infinite' with a goto address / symbol
action?
This is one of the main requirements for the viewer.
Both, the disassembly window and the memory rendering will be "infinite" and
have "GoTo" actions. Sorry, I wasn't
clear.
Regards,
Mikhail
Looks good
Mikhail.
A couple quick
questions:
1) The disassembly window you describe seems
explicitly tied to a debug session. Will there be any way of using the
disassembly view outside of debug contexts? For example: In the
Binaries explorer in the C/C++ Projects View you can view files compiled into
the binary (or symbols, depending) -- it would be a neat feature if there
was an action to view disassembly, so you can view both source and disassembly
within Eclipse without needing to launch a debug session, or firing up
objdump.
I think this is a more general problem. I
think ISV's hooking into CDT, not only want to be able to open source Editors
from the views, but probably also would like the flexibility of finding an
address / symbol in the disassembly view. They could use either a default
gdb instance to provide disassembly or provide their own as well as have the
ability of updating the context of the disassembly
view.
2) You say " as well as the ability to disassemble an arbitrary range of
memory. The latter can be implemented as a special memory rendering for the
Platform memory view." Given (1), I don't see why there should be any
restrictions on address range disassembled. Is there any reason not to
have the disassembly view 'infinite' with a goto address / symbol
action?
Cheers,
James
Hi,
Currently
I am working on the document that describes the viewer proposals
and trying to prototype it at the same time (or vice versa I should
say). I'll try to post it as soon as
possible.
Regards,
Mikhail
Khodjaiants
ARM
Limited
--
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.
