🚀 go-pugleaf

>> I've tried using gdb a lot in the past few days and I'm amazed at how
>> bug-ridden it is.  Many times, ...
>> 			... routinely fails.      Sometimes ...
>> It's so bad I almost feel I have no debugger.  Normally I have great
>> respect for software from the FSF but this is terrible.

>If you ever report any of these bugs, they might get fixed.

>Rumors of bugs, and slanderous comments, are not bug reports!  It's hard to
>fix a rumor of a bug.

>	John Gilmore


I, too, have been working without a debugger for the past several months. Since
I switched to shared libraries, I have been forced to do all my debugging with
print statements. 

I've reported problems twice to bug-gdb, and had no reponse both times.  I must
assume this was an accidental oversight. Let me try again:


========== BEGINNING OF MESSAGE ==========


Subject: gdb doesn't work with shared libraries!

I am using GDB 4.7 and a Sparc running SunOS 4.1.1. It doesn't work.

I try to debug a program, and insert a breakpoint. gdb dies immediately.
Example: 

  hancock% gdb net_controller
  GDB is free software and you are welcome to distribute copies of it
   under certain conditions; type "show copying" to see the conditions.
  There is absolutely no warranty for GDB; type "show warranty" for details.
  GDB 4.7, Copyright 1992 Free Software Foundation, Inc...
  (gdb) break main
  Segmentation fault (core dumped)

A backtrace of gdb is included, for your convenience. It means nothing to me.

  hancock% gdb ~/bin/gdb core
  GDB is free software and you are welcome to distribute copies of it
   under certain conditions; type "show copying" to see the conditions.
  There is absolutely no warranty for GDB; type "show warranty" for details.
  GDB 4.7, Copyright 1992 Free Software Foundation, Inc...
  Core was generated by `gdb'.
  Program terminated with signal 11, Segmentation fault.
  #0  0x2bb5c in decode_line_1 (argptr=0xf7ffedf4, funfirstline=1, default_symtab=0x0, default_line=0) at symtab.c:1838
  1838		  pc = BLOCK_START (SYMBOL_BLOCK_VALUE (sym)) + FUNCTION_START_OFFSET;
  (gdb) where
  #0  0x2bb5c in decode_line_1 (argptr=0xf7ffedf4, funfirstline=1, default_symtab=0x0, default_line=0) at symtab.c:1838
  #1  0x9f44 in break_command_1 (arg=0x159012 "", tempflag=0, from_tty=1) at breakpoint.c:1497
  #2  0xa310 in break_command (arg=0x15900e "main", from_tty=1) at breakpoint.c:1582
  #3  0x3684 in execute_command (p=0x15900e "main", from_tty=1) at main.c:931
  #4  0x3904 in command_loop () at main.c:990
  #5  0x33d8 in main (argc=2, argv=0xf7fff094) at main.c:857
  (gdb) 

I suspect the problem is related to my use of shared libraries, but this is not
negotiable. Having used shared libraries, I would never consider going back to
static libraries. 

I am using Sun's acc compiler with -g option. I cannot use gcc for a few
reasons. One of these is that gcc refuses to link to shared libraries when -g
is specfied. (This seems to be a very serious defect. Do you know when the gcc
maintainers are planning on correcting this?)


========== END OF MESSAGE ==========


So, could someone PLEASE help me with the three main points of the included
message:

1) Why does gdb die when I insert the breakpoint (any function, not just those
in the libraries; for example, main())?

2) If this bug gets fixed or a workaround is given, will I be able to debug
shared libraries if compiled with -g? I absolutely require this capability.

3) Why doesn't and when will gcc allow the linking of shared libraries with a
program compiled with -g?


and
4) (this is not a flame; I'm asking as gently as I can, but:) why has this
message been ignored by bug-gcc both times I have sent it (most recently on
1-december, first in summer-92)?


David Cogen