🚀 go-pugleaf

I'm writing to report a problem I'm experiencing with gdb 4.5 running on a
Sun SPARCstation 2, kernel architecture "sun4c", application architecture
"sun4", under SunOS Release 4.1.1.

The compiler is the SunOS 4.1.1 bundled compiler (/usr/ucb/cc). The
programs are compiled with the "-g" option only, and to test this problem,
have been linked both statically (-Bstatic) as well as dynamically
(-Bdynamic).  Both kinds of bindings performed identically (with respect
to this problem).

Gdb is being run from within emacs version 18.58.1.

The problem is that with some programs, once they are started under gdb,
gdb does not keep track of the call stack frames, so that a `bt' command
will always report that you are in the topmost frame. For example, with
the current project I am working on now (pfc), with a breakpoint at main:

    Breakpoint 1, main (argc=1, argv=0xf7fff4ec) at pfc.c:61
    (gdb) bt
    #0  main (argc=1, argv=0xf7fff4ec) at pfc.c:61
    (gdb)

After I step into the first function, and try `bt' again, this is the
result:

    (gdb) bt
    #0  pfc_get_env_parm (type=3, name=0x5c072 "PFC_DEBUG",
	    default_value=0x5c07c "0", buffer=0x88a44, size=0) at pfc.c:344
    (gdb)

When this routine returns to the topmost frame, I step into another
function, with the same results:
 
    (gdb) bt
    #0  pfc_setup_publishers (publisher_list=0x8ccd0) at pfc_publish.c:35
    (gdb) 

Basically, no matter where I stop my program, every time I issue the `bt'
command, gdb says that I am in the topmost frame (frame #0). Also, in some
cases (not shown above), gdb fails to print the values of the function's
parameters (it either shows empty parentheses () or question marks for the
value "parm=???").

Finally, this behaviour is not exhibited with _every_ program I try to
debug. A simple test-case program I wrote with several levels of function
calls did not cause gdb to exhibit this problem. I have seen this problem
with gdb infrequently in the past, but I'm not quite sure what causes it
or what makes it go away. I'm not sure whether it's the program, the
compiler or gdb; but an additional fact is that when I repeat the above
experiment with dbx (which I avoid using at any cost) and the same
executable, dbx successfully shows the call stack and the parameters at
any point I care to stop at and look.

I am wondering if other people using a similar development environment
have reported a similar condition, and if there is something I can do to
fix it.

If you have never heard of this problem before, I can send you a copy of
the program so you may try to reproduce it. But, since it is inconvenient
to do this (there are half a dozen files involved), and there is also a
chance you know what the problem is from my description, I'll refrain from
sending any source with this note.

In the meantime, I am building gcc 2.1 to see if the same problem occurs when
my program is compiled with gcc.

Thank you & best regards,
Nick.
--
 Nicholas Gianniotis                              phone: +81 3 5251-1136
 CS First Boston (Japan) Limited                  fax:   +81 3 3508-4427
 Asahi Seimei Hibiya Building                     email: next8!nico@bmt.gun.com
 5-1, Yurakucho 1-chome, Chiyoda-ku, Tokyo 100, Japan.