Re: Disassembly Window

[James Ingham <jingham at cygnus dot com>]

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