[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-dd-dev] Memory View Technology Subgroup Discussion
|
Hi Samantha,
TI has signed up to participate for the DSDP project for the disassembly
window. Technically, I am supposed to be responsible to gather the
requirements. I was busy in the past months on our commercial product
and I apologize for my lack of attention to the disassembly window
discussions.
Below is my respond to your requirements to the disassembly rendering
for the memory window, and hopefully, I should be able to update the
twiki website next week with the requirements from disassembly view
discussion threads. There seems to be a lot of discussion in multiple
threads, and I need to read through all the threads and documents them
on the twiki website.
I think the first two requirements can be combined into one requirement.
I don't think it is necessary to have to two rendering, one to show
generic disassembly and another to show mixed mode. You can always treat
the first case without source line interlace in the mixed mode. I think
it will be sufficient to provide an option to toggle source line on/off.
Additionally, I would like to add these requirements for you to
consider,
* symbol display in disassembly mode and mixed mode
* background color i.e instruction can be cached in different layer in
cache, and I need to be able to show different color to identify the
cache layer of each instruction.
* foreground color, it will be very valuable to be able to control the
color of each column i.e address, opCode, disassembly text, etc...
* virtual scrolling (maybe this is what you have in your last bullet).
* able to set multiple breakpoints on the same line (software, hardware,
more software, etc...)
* multiple PC indicators
* ability to indicate to user that the instruction might not be correct
(on some architecture, it is not possible to calculate a valid start
address by decoding the program on the target, this is the case for
variable opCode size target)
* resizable left margin (all the icon can be view by making the margin
bigger)
* copy text to clipboard
* print support (address range, current visible area)
* in-place editing of binary data (opCode)
* run to cursor
* set pc to cursor
* shouldn't blank out the view when target is running...
There are a lot of requirements here, and I don't expect that all will
be accepted/implemented for the next release. I am hopping that some of
these will make it.
With all these requirements, I am not so sure the memory window is the
right place to show disassembly or not. It looks like that I am asking
for a lot here, and maybe the existing disassembly will be a better
place to add all these requirements.
Thanks,
Patrick
-----Original Message-----
From: dsdp-dd-dev-bounces@xxxxxxxxxxx
[mailto:dsdp-dd-dev-bounces@xxxxxxxxxxx] On Behalf Of Samantha Chan
Sent: Tuesday, May 23, 2006 3:52 PM
To: Device Debugging developer discussions
Subject: Re: [dsdp-dd-dev] Memory View Technology Subgroup Discussion
Hi -
Yes, I agree that we probably need both, pure disassembly mode and a
mixed
mode (interlacing source and disassembly).
In some cases, e.g. when showing disassembly in the Memory View or when
debug information is not available, it may not be possible to show
source
interlacing with disassembly. This is when the pure disassembly mode
comes
in handy.
This is a summary of the disassembly rendering requirements and I will
document this onto the wiki page:
* Need a generic disassembly rendering
* Need a generic mixed mode disassembly rendering where source is
interlaced with disassembly (Maybe we can have one rendering that
supports
both modes. This is something that we can discuss.)
* We need to be able to show source and disassembly rendering side by
side. There needs to be some integration between the source editor and
the
disassembly rendering.
* Highlighting in a disassembly rendering can be controlled by some
context provided by the source editor. (e.g. We need to be able
highlight
more than one disassembly statements based on the cursor location from
the
source editor.)
* Highlighting in the source editor can be controlled by some context
provided by the disassembly rendering. (e.g. If the user highlight some
disassembly statements, the source editor should highlight their
corresponding source.)
* We need to show these renderings in the Memory View and possibly in an
editor.
* In the case when the renderings are shown in an editor, we need to be
able to support breakpoints, stepping, and run to line actions.
* Need to be able to render some random memory location to disassembly.
In
the case where source is available, render memory in mixed mode.
Let me know if I miss anything...
Thanks...
Samantha
Kirk Beitz
<kirk@freescale.c
om>
To
Sent by: Device Debugging developer
dsdp-dd-dev-bounc discussions
es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>
cc
05/22/2006 05:52
Subject
PM Re: [dsdp-dd-dev] Memory View
Technology Subgroup Discussion
Please respond to
Device Debugging
developer
discussions
<dsdp-dd-dev@ecli
pse.org>
samantha ++
on a separate sub-topic ... back to disassembly ...
regarding specifically what you stated: "Intead of having them
interlaced, source and disassembly are shown side-by-side."
- for some situations, interlacing source & disassembly is
probably still a desired use case by many of our current
users who will still want this as we go to eclipse.
i envisioned a scenario of a disassembly view very much as
ted had proposed, where no matter how much stepping occurs,
the "disasm" view remains forward, with source interleaved
for all addresses within the view.
wouldn't it be possible to simply have two variants of the
rendering engine, one that produces straight assembly for
this view, and the other which interleaves source into it?
- for other situations, the side-by-side view will be the only
way to go. we have optimized code debugging scenarios where
there is not necessarily a 1-to-1 mapping in either direction
when it comes to the generated code. this presents 2 problems:
one is that interleaved mixed-mode becomes meaningless. two
is that it becomes necessary in the side-by-side view to be
able to highlight several non-contiguous lines of assembly
per source, or even in some cases, several non-contiguous
lines of source for a single assembly instruction.
to go with all of this, we'd certainly like the ability to
take any random bit of memory shown in the memory view and
have it be rendered as assembly as well as mixed/interleaved
in appropriate cases.
thanks,
++ kirk
Samantha Chan wrote:
> Hi Ted -
>
> Here's how I envision this to work when embedding a disassembly
rendering
> in the editor. The editor could be a mult-pane editor. It has two
panes,
> a source pane and an optional disassembly pane.
>
> The source pane acts as the master of the editor. The disassembly
pane
> acts as a slave to the source pane. The content of the disassembly
pane
is
> controlled by the cursor location of the source pane, meaning that we
can
> show instructions that are associated with the selected line of source
> code. The disassembly rendering should also be able to show
disassembly
> from an arbitrary address.
>
> When a debug session is suspended, an instructional pointer is put in
the
> source pane. The disassembly pane would show disassembly code from
the
> current source line. It should also have an instructional pointer
placed
> at the current instruction. Depending on which editor has focus,
stepping
> could mean different things. If the source pane has focus, stepping
would
> mean stepping a line of code. If the disassembly pane has focus,
stepping
> would mean stepping a line of instruction.
>
> You can continue to edit source from the source editor. (Not sure if
hot
> code replace is possible, but if you edit a line of source, the
disassembly
> pane can be updated to show changes too...)
>
> When debugging, user has the option of hiding the source pane and only
look
> at the disassembly pane. I think this is a different way of having a
mixed
> mode where source and disassembly are shown together. Instead of
having
> them interlaced, source and disassembly are shown side-by-side.
>
> Of course, when the debug session is terminated, the disassembly pane
> should be removed / hidden. Also need to think about how breakpoints
> should be handled in this case.
>
> This makes it more obvious that the disassembly source is generated
and
> that user cannot edit the disassembly source. But user can continue
to
> edit the source code from the source pane.
>
> Thanks...
> Samantha
>
>
>
>
>
> "Williams, Ted"
> <ted.williams@win
> driver.com>
To
> Sent by: "Device Debugging developer
> dsdp-dd-dev-bounc discussions"
> es@xxxxxxxxxxx <dsdp-dd-dev@xxxxxxxxxxx>
>
cc
>
> 05/17/2006 08:44
Subject
> PM RE: [dsdp-dd-dev] Memory View
> Technology Subgroup Discussion
>
> Please respond to
> Device Debugging
> developer
> discussions
> <dsdp-dd-dev@ecli
> pse.org>
>
>
>
>
>
>
>
>
> Samantha> "What I meant was that if the editor that we use implements
> the IMemoryRenderingContainer and IMemoryRenderingSite interfaces, an
> editor can potentially display a memory rendering. In this case, the
> disassembly rendering can be shown in the editor. We can resuse the
> code in a disassembly rendering and do not have to come up with two
> different solutions for showing disasembly in the Memory View and in
an
> editor."
>
> When I think of mixed mode, two distinctly different use cases come to
> mind: source based and address based. Source based (mixed mode) is
> useful when I'm debugging source. I might instruction step in this
mode,
> but mainly, I enable it because I'm curious which instructions were
> generated by the compiler. I think the editor provides the better
> experience for this mode. I often edit while I'm stepping, if only to
> add comments. When I do edit code, completion and syntax highlighting
> are essential -- I don't see any advantage to editing source outside
of
> the editor. The second mode, address based, is useful when my focus is
> instruction stepping. No matter how many times I step, I never leave
the
> frame. Additionally, this mode allows me to see instructions beyond a
> single source file. The memory view is a close fit, but its real
estate
> is poor. I want to step disassembly in the editor region, where there
> will be sufficient width for the interspersed source lines.
>
> Samantha, can you elaborate on your proposal (above)? A disassembly
> editor could implement IMemoryRenderingContainer and share the memory
> view rendering. This sounds useful for the address based mode. But,
how
> would the rendering enhance the source based mode? What would the
> connection be between the source editor and the memory rendering?
>
> ted
>
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>
>
> _______________________________________________
> dsdp-dd-dev mailing list
> dsdp-dd-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
>
>
--
- Kirk Beitz - vox:(858)272-8858 - fax:(858)273-8858 -
cell:(619)888-9408 -
- mailto:kirk@xxxxxxxxxxxxx - CodeWarrior -
http://www.codewarrior.com -
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
