binutils, bugs in gdb, & "fixes" to gdb

binutils, bugs in gdb, & "fixes" to gdb

Post by Benjamin Redelings » Fri, 17 Oct 1997 04:00:00

Hi, I've found some errors in gdb which make it unable to step into or
over certain functions.  Specifically, when I try to step into these
functions gdb jumps to some random functions (always the last line in a
file) without even making an ew stack frame... it just overwrites the
existing one!!  Then, if I try to go on (or if I just try to step over
the function) gdb just continues as if I had pressed "c".
        My gdb is 4.16-6 precompiled from RedHat for RedHat 4.2.  (And I'm
running 2.0.30 on a PPro with gcc-  Firstly, I was suspicious
about the suposed "fixes" to gdb (6 of them!)  I can't find much info on
these, and GNU doesn't seem to have added any of them to the official
distribution... are they really good, or might they be causing my bug?
Also, I wonder if my bug might be caused by Red Hat's providing a binary
that is linked or compiled with old binutils.
        Has anyone else had problems with gdb jumping to the wrong place?  (I
had another problem before, when g++ emitted code for a default
operator=, got it mixed up with MY operator=, and then tried to let gdb
step into ITs operator= :)  If there is a better place to discuss this,
or any good place for finding gdb info, please let me know.  
        Anyone know if a new release is expected anytime soon?



1. strange behavior from "gdb" and "ObjectCenter"

I've recently noticed an odd problem that I can repeat with both
ObjectCenter and gdb, on Solaris 2.3.

My simple test case looks like this:

int main(int argc, char *argv[])

If I compile and link this, load it into either gdb or objectcenter,
run it, wait for the first "printf" to finish, and then press ^C to
get back to the debugging prompt, I then enter:


and press return (in "gdb", I need "call" before the printf"), I
should see the function execute and print "3".  However, what happens
is exactly nothing.  The cursor goes to the left margin and nothing
happens.  I waited quite a while and then thought to press Return.  It
then executed the printf.  I then tried changing the "getchar" to a
call to "sleep(30)".  Instead of having to press Return, I just waited
about 20 seconds more and then it executed the printf.

I also found that if I set a breakpoint at "printf" and called the
function from the prompt, it would hit the breakpoint before going
into idle mode.  When I continued from the breakpoint, it then went
into idle mode.

In addition, I tried setting breakpoints in the application and
waiting until the debugger hit the breakpoint.  At that point, I would
try calling the printf from the prompt, and that worked fine.

I have not upgraded my versions of "gdb" (4.14) or "objectcenter"
(2.1).  I don't remember when I last saw this scenario work correctly
(I've used this scenario for real work many times in the past).  It's
possible I've updated the jumbo patch on my workstation since then,
but I also repeated this on another workstation with an older jumbo
patch.  It is possible that this stopped working about the time we
moved to using ClearCase, however my test case isn't in a MVFS
filesystem, so it doesn't seem like it would matter.

2. How to create a POP accounts on a Linuy machine. (need to use

3. gdb:"next" works as "step"

4. INN nntp posting with in.nnrpd -> Segmentation fault

5. GETSERVBYNAME()????????????????????"""""""""""""

6. Forcing users to change password on first login

7. "System too big" & details on console.c "Illegal asm or bug".

8. Upgrading Linux

9. """"""""My SoundBlast 16 pnp isn't up yet""""""""""""

10. Slackware 2.2 bug: binutils "strings" incompatible with installpkg

11. GDB - "running program??!!!"

12. gdb-4.5, g++-2.1, String "unknown struct"?

13. gdb /w 4.3: libcrypt.a "not in proper exe format"