Disassembly Window

Disassembly Window

[Steven Johnson]

Regarding the Code Display Window,

Is Insight supposed to show disassembly of the current PC in the main
code window before any code is loaded? Is there a way to enable this?
This may not make sense to some people, but for an embedded target like
mine, just because I havent explicitly loaded a program does not mean
the disassembly is not interesting, in fact its exactly the opposite.

Regards,
Steven Johnson

Re: Disassembly Window

[Fernando Nasser]

I have exactly the same problem.  I am connecting to a hardware emulator
and the code is already there (I may not even have the source code at
all).

But it should be an option (as opposed to always on).  

Jim, It would be nice if we could add it, don't you think?

Fernando

P.S.: Steven, are you volunteering? ;-)



Steven Johnson wrote:
> 
> Regarding the Code Display Window,
> 
> Is Insight supposed to show disassembly of the current PC in the main
> code window before any code is loaded? Is there a way to enable this?
> This may not make sense to some people, but for an embedded target like
> mine, just because I havent explicitly loaded a program does not mean
> the disassembly is not interesting, in fact its exactly the opposite.
> 
> Regards,
> Steven Johnson

-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Re: Disassembly Window

[James Ingham]

Fernando, and Steven,

I am of two minds about this.  

I agree that being able to inspect memory on the board before the
program has been loaded is a good idea.  But I wonder if the source
window is the correct place to do this.  You really want to be able to
point at any region of memory disassembly that.  However, you may not
have references to that code anywhere in your sources.  So it seems
like overloading the source windows methods for finding what it is
going to display is not the best way to do it.  

Also, the memory display in the Source window is routine based or file
based, for disassembly, it wants to do a whole function.  So in cases
where you don't know when a function begins & ends, its display
paradigm doesn't really work.

Better would be to have two modes for the Memory window, one that
displays raw memory, and one that displays the given region of memory
as disassembly.  This is a more natural interface, since you just go to the
memory window and type in the address where your ROM code, or
whatever, resides, and you can see it.  You can also easily control
how much gets displayed by how far you open the window.

Actually, there are really three useful states for the Memory window,
raw memory, view as disassembly, and view as an array of some given
type.

These other two modes have been on my TODO list for a while now, but I
haven't had time to get around to them.  This is a bit more work
(though just to hack in the disassembly display here is not that bad.
But I think it is a better solution in the long term.  What do you
think?

And I echo Fernando, if you want to try your hand at this Steven, I
will help you get started.  Insight is not that hard to work on, but
it is much less well documented than it should be, mostly just
comments in the code, sadly enough.  Another item on the TODO list...

Jim

 > I have exactly the same problem.  I am connecting to a hardware emulator
 > and the code is already there (I may not even have the source code at
 > all).
 > 
 > But it should be an option (as opposed to always on).  
 > 
 > Jim, It would be nice if we could add it, don't you think?
 > 
 > Fernando
 > 
 > P.S.: Steven, are you volunteering? ;-)
 > 
 > 
 > 
 > Steven Johnson wrote:
 > > 
 > > Regarding the Code Display Window,
 > > 
 > > Is Insight supposed to show disassembly of the current PC in the main
 > > code window before any code is loaded? Is there a way to enable this?
 > > This may not make sense to some people, but for an embedded target like
 > > mine, just because I havent explicitly loaded a program does not mean
 > > the disassembly is not interesting, in fact its exactly the opposite.
 > > 
 > > Regards,
 > > Steven Johnson
 > 
 > -- 
 > Fernando Nasser
 > Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
 > 2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
 > Toronto, Ontario   M4P 2C9              Fax:  416-482-6299
 > 

-- 
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham                                              jingham@cygnus.com
Cygnus Solutions, a Red Hat Company                      

Re: Disassembly Window

[Duane Ellis]

I would also add that in this case, it is also quite valid to examine
registers *BEFORE* you start execution of the target application.

About the idea of doing this in the memory window....

jim> You really want to be able to
     point at any region of memory disassembly that	

I think the source window is really the place to put it, for the
simple reason that you may also want to be able to set break points in
that window too.

What sucks is you can type a function name in the source window,
but I cannot seem to type an address in the source window.

Maybe the memory window should go away, and be added as a selection
at the bottom of the screen that is "Source, Mixed, Assembly, ...."

-Duane.

Re: Disassembly Window

[James Ingham]

Duane,

 > 
 > I would also add that in this case, it is also quite valid to examine
 > registers *BEFORE* you start execution of the target application.

This is possible, though not as easy as it should be.  If you open the
target settings (from File->target settings), fill in the info about
the connection, and open the "More Options" panel and turn off
downloading and continuing, close this and hit the run button, Insight
will connect to the target.  You can do the download later from the
Run menu.  After you are connected, the registers window will actually
show you the registers on the target.

 > 
 > About the idea of doing this in the memory window....
 > 
 > jim> You really want to be able to
 >      point at any region of memory disassembly that	
 > 
 > I think the source window is really the place to put it, for the
 > simple reason that you may also want to be able to set break points in
 > that window too.
 > 

I disagree.  If you want to set breakpoints on random areas in memory
that gdb knows nothing about, then you should do so from the console
window.  Actually, it would also be nice to have a simple little "set
breakpoints" dialog that you can just type a symbol into, and gdb
would set a breakpoint there, or to add this functionality to the
Breakpoints window.  That would give you what you need without
overburdening the Source window.

Alternatively, when the Memory window is in disassembly mode, you
could add bindings to set breakpoints (or a popup menu to do the same.)

 > What sucks is you can type a function name in the source window,
 > but I cannot seem to type an address in the source window.

The source window is telling you what it knows about the executable in 
the drop down boxes.  I am semi-okay with typing into it (though it
ought to do some kind of auto-completion) but I always have doubts
about whether you should allow type-in to windows with a finite set of 
right choices.  It just seems like asking for errors.

Anyway, the Source window shows stuff that gdb has symbols for, not
random bits of memory.  For it to show just random memory we would
have to add some UI to determine "how much" you want to see.  You
can't really just do a page, because that is not how the source window 
works in its other instantiations.  This would confuse its main uses
to no real gain.

 > 
 > Maybe the memory window should go away, and be added as a selection
 > at the bottom of the screen that is "Source, Mixed, Assembly, ...."
 > 

No, this would be overloading its functionality way too much.  I don't 
think this is a good idea.

Jim

Re: Disassembly Window

[Steven Johnson]

James Ingham wrote:
> 
> Duane,
> 
>  >
>  > I would also add that in this case, it is also quite valid to examine
>  > registers *BEFORE* you start execution of the target application.
> 
> This is possible, though not as easy as it should be.  <snip>

I didnt have any problem here. Maybe its because I always turn of automatic
download options.

> 
> I disagree.  If you want to set breakpoints on random areas in memory
> that gdb knows nothing about, then you should do so from the console
> window.  Actually, it would also be nice to have a simple little "set
> breakpoints" dialog that you can just type a symbol into, and gdb
> would set a breakpoint there, or to add this functionality to the
> Breakpoints window.  That would give you what you need without
> overburdening the Source window.
> 
> Alternatively, when the Memory window is in disassembly mode, you
> could add bindings to set breakpoints (or a popup menu to do the same.)
> 
<BIG Snip>

I agree with Jim. This would be the best way to do it in my opinion. 

Open a Memory window, select to see data RAW or Assembly or some other format
(Like formated bitmap representation perhaps?). 
Have an option to highlight the current PC in the Memory Window. 
Have the ability to (say using the right mouse button) select a memory object
and put a breakpoint on it.

I Say this not lightly, I think this would be the ideal method because it
would give a unified means of setting both data access and code execution
breakpoints. Something I really want to be able to do. It would be much better
(more intuitive?) than having some cryptic dialog for setting up data access
breakpoints.

On the subject of enhancing insight, I thought Id just stick my wishlist
below. These are all things im going to do at some time if someone else doesnt
do them.

1. Ability to view memory as an arbitrary sized bitmap in various formats (1
bit per pixel, up to 32 bits per pixel.)
2. Ability to add cutom extensions without hacking the standard code base of
Insight. (Sort of allowing a user to add special macros for performing test
functions and the like specific to their development.) The Plan here is to
have a path set up that is added to the TCL search path for code and define a
standard extension entry/exit object/methods so that when insight starts it
can look for this standard extension and if it finds it, start it. Otherwise
it does nothing and assumes there is no extension. 
3. Add Automatic Hiding of Registers that GDB reports as not implemented
because a Target has reported them using the remote protocol (Im not sure if
there are other mothods of setting this) as unimplemented. Namely when a
target responds to a register read request with 'xxxxxxxx' dont show those
registers by default. (If at all).

The reason why i'm mentioning these is that I plan to do them sometime soon
and Id like the input of anyone that has an interest.

Regards,
Steven Johnson

Re: Disassembly Window

[James Ingham]

Steven Johnson writes:
 > James Ingham wrote:
 > > 
 > > Duane,
 > > 
 > >  >
 > >  > I would also add that in this case, it is also quite valid to examine
 > >  > registers *BEFORE* you start execution of the target application.
 > > 
 > > This is possible, though not as easy as it should be.  <snip>
 > 
 > I didnt have any problem here. Maybe its because I always turn of automatic
 > download options.
 > 

Yeah, I think one bug here is that it is hard to poke at your board if
you don't have an executable file loaded into Insight.  We think that
you ARE going to try to download, so we will helpfully prompt you for
a file, and if you say cancel, we abort the connect.  Probably not
right, but you have to be careful, because if you do connect, and then
later do the "file" command, gdb resets the target, so we would have
to put that to rights again.  This is a little akward, but it doesn't
keep me up at nights.

 > > 
 > > I disagree.  If you want to set breakpoints on random areas in memory
 > > that gdb knows nothing about, then you should do so from the console
 > > window.  Actually, it would also be nice to have a simple little "set
 > > breakpoints" dialog that you can just type a symbol into, and gdb
 > > would set a breakpoint there, or to add this functionality to the
 > > Breakpoints window.  That would give you what you need without
 > > overburdening the Source window.
 > > 
 > > Alternatively, when the Memory window is in disassembly mode, you
 > > could add bindings to set breakpoints (or a popup menu to do the same.)
 > > 
 > <BIG Snip>
 > 
 > I agree with Jim. This would be the best way to do it in my opinion. 
 > 
 > Open a Memory window, select to see data RAW or Assembly or some other format
 > (Like formated bitmap representation perhaps?). 
 > Have an option to highlight the current PC in the Memory Window. 
 > Have the ability to (say using the right mouse button) select a memory object
 > and put a breakpoint on it.
 > 
 > I Say this not lightly, I think this would be the ideal method because it
 > would give a unified means of setting both data access and code execution
 > breakpoints. Something I really want to be able to do. It would be much better
 > (more intuitive?) than having some cryptic dialog for setting up data access
 > breakpoints.

Yes, this would be cool.  The other thing I really want is that when I 
have a "struct foo *" object, I want to be able to tell gdb to pretend 
that it is a foo[10], and get the nice little turndown variable
display.  This is relevant to memory, 'cause I want to be able to do
this anywhere in memory...

 > 
 > On the subject of enhancing insight, I thought Id just stick my wishlist
 > below. These are all things im going to do at some time if someone else doesnt
 > do them.

Coolo!

 > 
 > 1. Ability to view memory as an arbitrary sized bitmap in various formats (1
 > bit per pixel, up to 32 bits per pixel.)

This would be nice.

 > 2. Ability to add cutom extensions without hacking the standard code base of
 > Insight. (Sort of allowing a user to add special macros for performing test
 > functions and the like specific to their development.) The Plan here is to
 > have a path set up that is added to the TCL search path for code and define a
 > standard extension entry/exit object/methods so that when insight starts it
 > can look for this standard extension and if it finds it, start it. Otherwise
 > it does nothing and assumes there is no extension. 

Yes, I really want to do this.  What I would like also is to have a
"Scripts" menu that would snag tools from a similar path search plus
file name convention type thingie, and post the results in the menu.

You can do some pretty cool things with the Tcl interpreter in gdb.

For instance, for the presentation I gave at this past Tcl conference,
I wrote a little script that scans the C stack of a Tcl application,
and reconstructs the Tcl stack, with arguments, from the C Stack each
time you stop.  It posts the results in a separate Tcl stack window.
It would be really cool to be able to stash that away somewhere, and
then go to the Scripts menu and say "Show me the Tcl code stack!"

We could also host a central set of the more general purpose of such
scripts in the Insight distribution.  It would make the tool much more
powerful.

Note, also, that these extensions need not be Tcl only.  If you wanted
to write some C code in the form of a shared library, and wrap Tcl
interfaces around it, we could use the Tcl "load" command to bring
these features into the interpreter living in Insight.  Doing this will
require a little more work, however.

First off right now, we link statically to the Tcl libraries,
and on some systems you can't load a shared library into an executable 
that has statically linked to a library the shared library also
requires.  This can be solved either by linking to Tcl dynamically, or 
by moving up to Tcl8.3 and using the "Tcl Stubs" mechanism.

Secondly, your C extensions will not be able to use GDB internal
functions.  To allow this, you would have to make a .so out of
libgdb.a, and link the gdb shell to that.  Then you could make a fully 
loadable extension module which calls into gdb, and provides access to 
its features through the Tcl interpreter.  Pretty cool, no?

 > 3. Add Automatic Hiding of Registers that GDB reports as not implemented
 > because a Target has reported them using the remote protocol (Im not sure if
 > there are other mothods of setting this) as unimplemented. Namely when a
 > target responds to a register read request with 'xxxxxxxx' dont show those
 > registers by default. (If at all).

This would also be nice...

 > 
 > The reason why i'm mentioning these is that I plan to do them sometime soon
 > and Id like the input of anyone that has an interest.
 > 

I think I will be occupied with bug fixing and such for the next
little while, so it is GREAT to have you work on some cool new
features like the ones you mentioned.  I probably have more opinions
about these subjects than you will find convenient over the long haul, 
but I am really happy to discuss your ideas.

Thanks,

Jim

-- 
++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++==++
Jim Ingham                                              jingham@cygnus.com
Cygnus Solutions, a Red Hat Company