🚀 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.

With regard to my previous note, I have since built the program using gcc
2.1, and gdb fails in exectly the same way as described above.

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.