From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Johnson To: James Ingham Cc: Insight Mailing List Subject: Re: Disassembly Window Date: Thu, 06 Apr 2000 14:18:00 -0000 Message-id: <38EC7171.D0D15F1B@ozemail.com.au> References: <38EA5ED1.827206D7@ozemail.com.au> <38EB5137.890574D3@redhat.com> <14571.27013.103290.130590@leda.cygnus.com> <200004051643.MAA15621@mercury.franklin.com> <14571.31690.682824.503403@leda.cygnus.com> X-SW-Source: 2000-q2/msg00024.html 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. 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.) > 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