Re: pending patches status ?

[toddpw@wrs.com (Todd Whitesel)]

> I use gdb for years now (starting with gdb-4.9), and I don't think it ever
> worked on my platform (m68k-motorola-sysv).  At least since years it doesn't,
> so that I thought it was a feature :
> "`step', `next' and `finish' are not allowed in breakpoints command lists".

I believe it was a deliberate feature limitation in order to prevent bugs,
that is, nested breakpoint command lists causing non-re-entrant code to get
re-entered.

It may be that those bugs no longer exist. But I doubt it, given the current
procedural implementation. As things move to be more event-driven I expect
this issue to become a lot easier to understand and resolve.

> What is perhaps new is the test, so I noticed that it was expected to work and
> I tried to find out why it did not work.  Of course, I feel the same concerns
> about the reasons of the code I turned off,  but I ran the whole testsuite
> on both m68k-motorola-sysv and powerpc-ibm-aix4.1.5.0 without new failures,
> so I think it is a safe change.

I do not know, but I expect that the test is new, and may even have been put
there by somebody who felt that this should work, and wanted to see if someone
else could fix it.

If you want to experiment with an asynchronous GDB, find a friend with a copy
of Tornado 2.0 from Wind River, and run the unix GDB's with the option
-async-woofy. Then go to another window and run a socket connector program;
it needs to be something simple that issues a single write per line of
terminal input (with a \n at the end). If you want to make the code smarter
(say to cope with telnet), search in top.c for the comment that reads:
	/* THIS IS EXTREMELY FLIMSY AND DOES NOT WORK IN GENERAL */

The second window becomes a very dumb (but asynchronous) command prompt.
The primary GDB window is used for output, queries, and inferior terminal I/O.

This mode of our GDB was used for testing on unix. The actual code is only
used by our win32 product but that will change in the future, unless GDB is
totally replaced by Look! (a high-powered C++ debugger whose company we
acquired last year).

I had to spend so much time on formal bug reports during the release that I
never got a chance to make the full command-line functionality or the
"compound" commands (source, plus the control commands) work nicely. To do
anything complicated, you pretty much have to source a script file and the
async prompt goes away while it is executing.

But the important thing is that you can attach without halting, and you can
play with breakpoints without stopping the inferior if the backend supports it.
It should be possible to view globals while the program is running, but we
didn't have that as a requirement so our GUI interface does not try to do it.

-- 
Todd Whitesel
toddpw @ wrs.com