From mboxrd@z Thu Jan 1 00:00:00 1970 From: Fernando Nasser To: duane_ellis@franklin.com Cc: insight@sourceware.cygnus.com Subject: Re: RFC: gdbtk/TODO file Date: Tue, 10 Oct 2000 18:32:00 -0000 Message-id: <39E3C346.F6AEFF4F@cygnus.com> References: <200010102229.SAA28413@mercury.franklin.com> X-SW-Source: 2000-q4/msg00047.html Hi Duane, thanks for your comments. Duane Ellis wrote: > > On Thu, 5 Oct 2000, Fernando Nasser wrote: > > > TODO: > > I live in an embedded world; I would add: > > 1) Better support for assembly language debugging. > > In mixed and assembly mode - in effect, the source window would be > a virtual window with no real top or bottom, and not be bound to > the limits of the C file you are viewing. > That one is hard. The problem is that we need a start point for disassembly in several architectures (pure RISC being an exception as any aligned address would do). Gdb and the debug information only provide us function limits. Also, with a source file being shown, what criteria would we use to go beyond the end (or start) of a source file? The linker may have laid things out in memory very arbitrarily. Following the memory addresses and tracking things backwards is even worse: quite dependent on reverse searches on function and line number information. Another point is that we want to be able to mix it with source code knowledge (for instance SourceNavigator's) to be able to Code/Build/Debug in the same environment. A good reason to keep the file and function/method units. > For instance, your I/O routines may be functions contained in a ROM > monitor (and not part of your program), and you would like to > assembly single step through them. > This is possible. Disassembly from memory at the PC as an alternative view is in my wish list. > Or maybe you have a library with no symbolic information but need > to debug anyway. > Same as above. > 2) A way of telling the GUI to reset and reconfigure it self. > > Change the program counter to an arbitrary address. Now tell > insight's source window (and all others) to fix them selves. > > ie: (gdb) set $pc=0x12345678 > > How do I get the GUI to update it self to the new PC location? > > (Happens with simulators & rom targets when you issue a target > command that GDB passes through and cannot understand) > I've run into this problem already. We need to fix gdb first as it is keeping stale information in this cases. We have been talking about a command to do something like flush register and memory caches in gdb. It will be possible to add a Refresh thing to the GUI after that. I forgot to add this to the TODO file though. Thanks for bringing it up. > 3) The Ability to run without a target, and no symbols. > [this is in a ROM or simulator world] > > Load and attach to the target (simulator or rom monitor) issue > various "target/simulator" commands that make the program load into > memory. (that GDB does not know about, nor can you explain to GDB > in any way) > > GDB can't seem to run unless it has loaded a file. That's not > always required. > Funny, I can run without load. There are some subtle differences between some variations of remote targets. Which one specifically are you using? -- Fernando Nasser Red Hat Canada Ltd. E-Mail: fnasser@cygnus.com 2323 Yonge Street, Suite #300 Toronto, Ontario M4P 2C9