[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [dsdp-dd-dev] Disassembly Presentation Discussion (formerly Memory View discussion)
|
Hi Mikhail -
Yes, I agree that the original request is to show disassembly as a Memory
View rendering, and nothing more. However, I just want to make sure that
this discussion is not lost. I am just trying to capture all the
requirements related to displaying disassembly. Maybe a better idea is to
start another thread to discuss showing disassembly in general. (i.e. move
this to the Disassembly Subgroup Discussion.)
> But I don't think it should be driven by the Memory view
> and there is no need to retrieve a memory block to convert it to
> disassembly.
The current definition of a memory rendering requires a memory block. So,
if you need to use the Memory View to show a disassembly rendering, you
would have to generate a memory block for it. We may need extension to
existing APIs, or maybe we need a new API as suggested by you.
To clarify showing disassembly rendering in an editor scenario, these are
the use cases that I can think of when user wants to see disassembly:
* The user is looking at some memory where their program is loaded and
executed. They may be interested in knowing what the disassembly
representation looks like. In that case, they may be working in a memory
block and wants to generate a disassembly rendering from it.
* The user maybe debugging something and doing some stepping. At some
point, they suspect that the disassembly code generated by the compiler is
incorrect. So, from the editor where they are looking at source, they may
want to look at a different representation of source. In this case, we may
want to show disassembly in the editor. We can show pure disassembly or
show source interlacing with disassembly. Of course, you can still show
the same information in the Memory View. But as Ted suggested, showing
disassembly allows us to save real-estate. In addition, it does not
require our users to switch between an editor and the Memory View when
working with disassembly.
All I wanted to bring up here is that we don't want to confine ourselves to
show disassembly in the Memory View. It may make sense to show it in an
editor or somewhere else.
> Providing a special (DSDP or Debug) editor is not a good
> solution. There are many editor providers who would like to integrate the
> disassembly presentation into their products. If there are plans to allow
> it, we should make it clear.
I agree with you on this. Providing a special editor is not a good
solution. Users should have a choice to use whatever editors they want,
even when they are debugging. We don't want to force clients to a special
debugger. I haven't really thought through how embedding a rendering in an
editor will be implemented. However, if we decide that this is what we
want, we may want to look at what enhancements we may require from the
editor framework. I don't think we can do this easily at the moment.
I hope this clarifies things a little. :)
Thanks...
Samantha
"Mikhail
Khodjaiants"
<mikhailk@xxxxxxx To
> "Device Debugging developer
Sent by: discussions"
dsdp-dd-dev-bounc <dsdp-dd-dev@xxxxxxxxxxx>
es@xxxxxxxxxxx cc
Subject
05/23/2006 05:17 Re: [dsdp-dd-dev] Memory View
PM Technology Subgroup Discussion
Please respond to
Device Debugging
developer
discussions
<dsdp-dd-dev@ecli
pse.org>
Hi Samantha,
The original request was to show disassembly as a Memory view rendering,
nothing more. Providing generic disassembly presentation interfaces seems
like a good idea. But I don't think it should be driven by the Memory view
and there is no need to retrieve a memory block to convert it to
disassembly.
My suggestion is to define the core interfaces to retrieve disassembly,
maybe as an extension of the IMemoryRerieval interface and use it as a base
for disassembly presentation instead of IMemoryBlock.
Another problem is the editor implementation. I am confused by this
discussion. Providing a special (DSDP or Debug) editor is not a good
solution. There are many editor providers who would like to integrate the
disassembly presentation into their products. If there are plans to allow
it, we should make it clear.
Thank you,
Mikhail Khodjaiants
----- Original Message -----
From: "Samantha Chan" <chanskw@xxxxxxxxxx>
To: "Device Debugging developer discussions" <dsdp-dd-dev@xxxxxxxxxxx>
Sent: Tuesday, May 23, 2006 3:51 PM
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
_______________________________________________
dsdp-dd-dev mailing list
dsdp-dd-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dsdp-dd-dev
