Pierre Muller pointed out that, in my post of July 2 on this topic, I forgot to indicate that the file to patch is `gdb/dbxread.c' under the source tree. Sorry.
Did you test it by using insight in non windowed mode
(with --nw option), then you get the normal text mode version of gdb.
In my original post I wrote:
insight running in non-graphical mode (with the --nowin flag ) does not exhibit this problem.
One difference, I think, between the two modes is that, in the graphical mode, the entire symbol table is read at the time the binary file is opened, whereas it is apparently NOT read, at least not by the same routine, in the text mode.
*** A few more details: If you use gdb on itself, as I did, and you break at line 2768 of dbxread.c, within fcn. process_one_symbol (which is the first line of my patch), you'll see that the context of the call is below `gdb_load_disassembly'. Apparently this fcn. is not called, or not in the same way, in the text mode. (Alternatively, in the unpatched source, line 2755 is the pop_context macro invocation where the problem occurs, and provides a suitable breakpoint for analysis. After fewer than 10 breaks, if memory serves, you arrive at one where context_stack_depth is already 0 - which is the problem situation. It's only easier to see this in the patched version because the variable is right in front of you. BTW, my procedure is to give `gdb gdb', set args to "" and run, and when the `debuggee' appears, to command it to open `smalltest' or some other program built with gpc 2.1.) *****
With regard to my post of July 3, "GPC2.1: all types "void" under gdb", please note that this problem can be easily observed in the text mode by using the "print" commmand.
Finally, as a user, I'd like to thank the developers collectively for an impressive and useful product.
Bob Scher