Re: Disassembly Window

[Steven Johnson <sbjohnson at ozemail dot com dot au>]

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