HDTenEightyP/NetNews huggingface dataset:
From: larus@cs.wisc.edu (James Larus)
Subject: Bug in gdb (version 4.6) on DECstation
Reply-To: larus@cs.wisc.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 18:49:51 GMT

The following patch fixes a problem in gdb (4.6) on a DECstation
(MIPS) that causes it to crash.  I can supply an executable that
provokes this bug if necessary.

/Jim

James Larus
Computer Sciences Department
1210 West Dayton Street
University of Wisconsin
Madison, WI 53706
larus@cs.wisc.edu
608-262-9519




*** mipsread.c	Tue Jul 21 13:03:55 1992
--- mipsread.c~	Mon Jul  6 12:10:58 1992
***************
*** 2993,3000 ****
  
  	/* But what symtab does it live in ? */
  	st = find_pc_symtab(SYMBOL_VALUE(s));
- 	if (st == 0)
- 	  return;		/* JL */
  
  	/*
  	 * Ok, there goes the fix: turn it into a procedure, with all the
--- 2993,2998 ----

Newsgroups: gnu.gdb.bug
From: Garrett.Wollman@uvm.edu (Garrett Wollman)
Subject: More gdb 4.6 on Irix 4.0.
Organization: University of Vermont, EMBA Computer Facility
Distribution: gnu
Date: Mon, 20 Jul 1992 15:41:55 GMT

I have found that the problem with `next'ing seems to be due to the
inability of gdb to deal with line numbers; in particular, it assigns
the whole PC range of main() to the first line.

If I ever get this working, I'm looking at adding follow-fork support
(that is, we catch PR_SYSEXIT for fork() and ask the user if the want
to continue debugging the old process, or attach to the new one),
unless someone has already done so.  Ideally this would be done as a
complete system-call tracing support...

Here is a simple bug in procfs.c:

--- procfs.c.orig	Mon Jul 20 11:00:49 1992
+++ procfs.c	Mon Jul 20 11:29:08 1992
@@ -2095,14 +2095,18 @@
   errno = 0;
   pi.prrun.pr_flags = PRSTRACE | PRSFAULT | PRCFAULT;
 
-#ifdef PRSVADDR_BROKEN
+#ifndef PRSVADDR_BROKEN
 /* Can't do this under Solaris running on a Sparc, as there seems to be no
    place to put nPC.  In fact, if you use this, nPC seems to be set to some
    random garbage.  We have to rely on the fact that PC and nPC have been
    written previously via PIOCSREG during a register flush. */
 
+/* This was #ifdef PRSVADDR_BROKEN, which didn't make any sense,
+ * since this code would use PRSVADDR iff it was `broken'... -GW
+ */
+
   pi.prrun.pr_vaddr = (caddr_t) *(int *) &registers[REGISTER_BYTE (PC_REGNUM)];
-  pi.prrun.pr_flags != PRSVADDR;
+  pi.prrun.pr_flags |= PRSVADDR;
 #endif
 
   if (signo && !(signo == SIGSTOP && pi.nopass_next_sigstop))


-GAWollman

-- 
   Garrett A. Wollman  = wollman@emba.uvm.edu = UVM is welcome to my opinions
                       =    uvm-gen!wollman   =
   That's what being alive is all about.  No deity, no higher goal
   exists, than to bring joy to another person.    - Elf Sternberg

Newsgroups: gnu.gdb.bug
From: joe@consolve.COM (Joe Shapiro)
Subject: Bug with re-reading symbols and setting breakpoints
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 22:40:15 GMT

Hi, Folks
    I'm using gdb 4.6 and gcc 2.2.2.  This problem also occurs with gdb 4.5.
If I run gdb on a program and then recompile the program, gdb gets confused
and is no longer able to set breakpoints.  Here's a VERY small example:



/home/joe/gnu-bugs /home/joe/c-saw
joe@somalia> echo 'main(){}' > a.c

/home/joe/gnu-bugs /home/joe/c-saw
joe@somalia> gcc -g a.c

/home/joe/gnu-bugs /home/joe/c-saw
joe@somalia> gdb a.out
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.6, Copyright 1992 Free Software Foundation, Inc...
(gdb) r
Starting program: /usr3/joe/gnu-bugs/a.out 

Program exited with code 01.
(gdb) 
Suspended

/home/joe/gnu-bugs /home/joe/c-saw
joe@somalia> gcc -g a.c

/home/joe/gnu-bugs /home/joe/c-saw
joe@somalia> %
gdb a.out
(gdb) r
`/usr3/joe/gnu-bugs/a.out' has changed; re-reading symbols.
Starting program: /usr3/joe/gnu-bugs/a.out 

Program exited with code 01.
(gdb) b main
Cannot access memory at address 0x2290.
(gdb) q

Newsgroups: gnu.gdb.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: environ.c should not apply memcpy to overlapping regions (GDB 4.6)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 23 Jul 1992 23:40:45 GMT

GDB 4.6's environ.c applies the memcpy routine to overlapping regions of
memory.  This isn't portable.  It should use memmove instead, but I suppose
that's too much of a pain to configure.  Here is a patch.

===================================================================
RCS file: environ.c,v
retrieving revision 4.6
diff -c -r4.6 environ.c
*** environ.c	1992/07/06 17:10:46	4.6
--- environ.c	1992/07/23 23:27:13
***************
*** 179,187 ****
  	&& s[len] == '=')
        {
  	free (s);
! 	memcpy (vector, vector + 1,
! 		(e->allocated - (vector - e->vector)) * sizeof (char *));
! 	e->vector[e->allocated - 1] = 0;
  	return;
        }
  }
--- 179,186 ----
  	&& s[len] == '=')
        {
  	free (s);
! 	while ((vector[0] = vector[1]) != NULL)
! 	  vector++;
  	return;
        }
  }

Newsgroups: gnu.gdb.bug
From: kells@iis.ethz.ch (Kevin Kells)
Subject: problems setting breakpoint in simple program (gdb-4.5)
Organization: Swiss Federal Institute of Technology (ETH), Zurich, CH
Distribution: gnu
Date: Fri, 24 Jul 1992 11:10:25 GMT

On a Sun Sparc running SunOS 4.1.1, I have the following C++ program
(compiled with g++ 2.0).

     1  #include <stdio.h>
     2
     3  main()
     4  {
     5    int i;
     6    for (i=0; i<10; i++)
     7      {
     8        if (i==i)
     9          printf("%d\n",i);
    10      }
    11    printf("Aha! %d\n",i);
    12  }

In gdb 4.5, I can set a breakpoint at line 11 with "break 11". When I
run the program, it prints 0 through 9 and then breaks. This is
correct behavior. 

Now I have this program:

     1  #include <stdio.h>
     2
     3  main()
     4  {
     5    int i;
     6    for (i=0; i<10; i++)
     7      if (i==i)
     8        printf("%d\n",i);
     9    printf("Aha! %d\n",i);
    10  }

I just took out the braces for the "for" loop. I would like once again
to set a break point before printing "Aha!", so I say, "break 9".
However, when I run the program, it prints 0 then breaks. When I hit
"c", it prints 1 and then breaks. This continues as if gdb couldn't
decide if the "Aha!" line was part of the loop or not (i.e., it breaks
as if it were part, but does not execute it after I hit "c"). After
finishing the count from 0 to 9, breaking after every number, it
finally prints the "Aha!".

Am I doing something wrong? (besides using older versions of the compiler
and gdb?) 

Kevin

--
Kevin Kells <kells@iis.ethz.ch>         telephone: +41-1-256-5746
Integrated Systems Laboratory, ETH-Zentrum, CH-8092 Zurich, Switzerland

Newsgroups: gnu.gdb.bug
From: silano@newton.cs.jhu.edu (Mike Silano)
Subject: GDB 4.6 and SCO corefile support
Organization: Johns Hopkins Computer Science Department, Baltimore, MD
Distribution: gnu
Date: Mon, 20 Jul 1992 18:09:23 GMT

I know that has probably been discussed (to death) in the past but I can't
seem to find any opf my saved articles on it..  So....

I've just compiled gdb 4.6 on an SCO Unix machine using GCC.  I cannot get 
gdb to read the core files produced on this system - unknown core format is  
the error.  

Any help on this? 

Thanks  

-Mike Silano


Newsgroups: gnu.gdb.bug
From: kumarb@pcsi.com (Kumar Balachandran)
Subject: gdb within emacs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 01:26:43 GMT

I installed gdb on a sparc 2, and it was running fine under emacs for a while
However, when I upgraded to emacs-18.58, gdb does not work any more. The message
I receive immediately specifying the file is that infereior gdb exited with 
code 1.

Kumar
kumarb@pcsi.com

Newsgroups: gnu.gdb.bug
From: neitzel@ips.CS.tu-bs.DE (Martin Neitzel)
Subject: Re: Execution trace feature for gdb
Summary: It's not sooo easy...
Organization: Inst. f. Informatik, TU Braunschweig, FRG
Distribution: gnu
Date: Tue, 28 Jul 1992 11:49:50 GMT

I just asked the same question about the "trace facility in the dbx
sense" three months ago and digged into the gdb source.

I found out that this functionality would require more than, say, a
twenty line patch.  The framework for integrating "trace points" as
another variant of break and watchpoints points is there.  The new
"trace" commands set would nicely fit into it (arguments/syntax just
like "break" commands with lots of code reuse possible).  I'd estimate
that modifications would mainly concern about three modules.

But at that time, I was just too busy with my regular work(*) to
figure out how to distribute the trace marks into the code (for a
"trace function fred" command).  I felt not being expert enough to
assess viability/quality my own idea for an implementation and didn't
any further work on it.  (A broad, two page overview about gdb's inner
concepts and workings would have been very helpful at that point.)

						Martin Neitzel

(*) Still am, sorry.

Newsgroups: gnu.gdb.bug
From: kevin@traffic.den.mmc.com (Kevin Rodgers)
Subject: Re: Execution trace feature for gdb
Organization: Martin Marietta Western Internal Systems, Technical Operations
Distribution: gnu
Date: Wed, 29 Jul 1992 18:57:52 GMT

In article <1992Jul28.114950.3647@ips.cs.tu-bs.de> neitzel@ips.CS.tu-bs.DE (Martin Neitzel) writes:
>I just asked the same question about the "trace facility in the dbx
>sense" three months ago and digged into the gdb source.
>
>I found out that this functionality would require more than, say, a
>twenty line patch.  The framework for integrating "trace points" as
>another variant of break and watchpoints points is there.  The new
>"trace" commands set would nicely fit into it (arguments/syntax just
>like "break" commands with lots of code reuse possible).  I'd estimate
>that modifications would mainly concern about three modules.

I'd like to add that the gdb command language itself could provide the
framework for integrating tracepoints, since:

(1) breakpoints can be specified by function name,
(2) arbitrary gdb commands can be associated with any breakpoint with
    the 'commands' command, and
(3) there is a mechanism for defining new commands ('define').

If 'define' could take an argument, e.g. a function name, then 'trace'
could be implemented something like:

define trace (function)
	break $function
	commands
		silent
		echo >
		info frame
		finish
		echo <
		info frame
	end
end

If 'define' is enhanced to accept arguments, it might be worthwhile to
allow optional arguments, so that for instance 'trace' could take an
optional 'if COND' clause that could be passed to 'break'.
-- 
Kevin Rodgers				kevin@traffic.den.mmc.com
Martin Marietta MS A16401		(303) 790-3971
116 Inverness Dr. East
Englewood CO 80112 USA			GO BUFFS!

Newsgroups: gnu.gdb.bug
From: mt00@etherm.co.UK (Martin Tomes)
Subject: Step/Next bug debugging single statement loops in g++
Organization: Eurotherm Controls Limited.
Distribution: gnu
Date: Wed, 22 Jul 1992 08:29:13 GMT

If I compile this program:

----------------------------------------
main()
{
  int i;
  for (i=0; i<10; i++)
    printf("Hello World\n");
}
----------------------------------------

With this command:

$ g++ -g -o hello hello.C

And run gdb:

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.6, Copyright 1992 Free Software Foundation, Inc...
(gdb) break main
Breakpoint 1 at 0x196: file hello.C, line 3.
(gdb) run
Starting program: /chough/mt00/tmp/hello

Breakpoint 1, main () at hello.C:3
3         int i;
Current Language:  auto; currently c++
Type checking:     auto; currently off
Range checking:    auto; currently off
(gdb) next
4         for (i=0; i<10; i++)
(gdb)
5           printf("Hello World\n");
(gdb)
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
Hello World
6       }

Both next and step go to the statement after the loop rather than
stepping round each iteration.  If I change the code by adding {}
thus:

----------------------------------------
main()
{
  int i;
  for (i=0; i<10; i++) {
    printf("Hello World\n");
  }
}
----------------------------------------

Compile and gdb again:

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.6, Copyright 1992 Free Software Foundation, Inc...
(gdb) break main
Breakpoint 1 at 0x196: file hello.C, line 3.
(gdb) run
Starting program: /chough/mt00/tmp/hello

Breakpoint 1, main () at hello.C:3
3         int i;
Current Language:  auto; currently c++
Type checking:     auto; currently off
Range checking:    auto; currently off
(gdb) next
4         for (i=0; i<10; i++) {
(gdb)
5           printf("Hello World\n");
(gdb)
Hello World
6         }
(gdb)
5           printf("Hello World\n");
(gdb)
Hello World
6         }

It now works.

I am using the following:

    - An Intel 33MHz 486 EISA machine.
    - ISC UNIX Version 3.0 with fix disk FD3.OS3.3
    - gcc 2.2.2 untouched compiled out-of-the-box.
    - gdb 4.6 with patches from the net to correct the following:
        * Reading of core files.
        * Mapping of the variable '.t' to 'this' so gdb can see the
          this variable.

Martin Tomes

Janet:    mtomes@uk.co.eurotherm
Internet: mtomes@eurotherm.co.uk
UUCP:     {uknet,uunet}!etherm!mtomes

Newsgroups: gnu.gdb.bug
From: hxl@chopin.UUCP (Charlie Xiaoli Huang)
Subject: support for hp 700 series
Organization: Gnus Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 17:13:54 GMT

Is there a plan to support HP's Precision Architecture cpu 
on the HP 700 series machines? With gdb4.4 configure aborts
saying that they are not supported. 

Thanks in advance,

hxl

Newsgroups: gnu.gdb.bug
From: tietz@gmd.DE (Christoph Tietz)
Subject: gdb-4.6 crashes on trivial program
Organization: GMD, Sankt Augustin, Germany
Distribution: gnu
Date: Thu, 30 Jul 1992 15:36:12 GMT

// This may look like C code, but it is really -*- C++ -*-
//
// Compiling with g++-2.2.2, linked with libg++-2.2 on a
// SUN4 (SPARCstation IPX) running SunOS 4.1.2:
//
// g++ -pipe -g -I/vol/gnu/lib/g++2-include -o qwrst qwrst.cc -lg++2
//
// Using gdb-4.6:
//
// The attempt to "debug" the following program crashes gdb:
// Set a breakpoint at the first line of function funcA (e.g. break funcA)
// and let the program run :-(

#include <stream.h>

class Dings {
public:
  virtual void bums ();
};

void Dings::bums () {}

typedef void (Dings::*dingsMem)();

void funcA (dingsMem a) {
  cout << "funcA\n";
}

main () {
  Dings a;

  funcA (a.bums);
}

------------------------------ snip here --------------------------------------

A session of gdb with gdb looks as follows:

Starting program: /vol/gnu/bin/gdb qwrst
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.6, Copyright 1992 Free Software Foundation, Inc...
gdb_qwrst> break funcA
Breakpoint 1 at 0x22b0: file qwrst.cc, line 22.
Current Language:  auto; currently c++
Type checking:     auto; currently off
Range checking:    auto; currently off
gdb_qwrst> run
Starting program: /tmp_mnt/home/tietz/sesame/qwrst 


Program received signal 11, Segmentation fault
0x1cca4 in val_print ()
gdb_qwrst> where
#0  0x1cca4 in val_print ()
#1  0x21798 in print_frame_args ()
#2  0xdb68 in print_frame_info ()
#3  0xd9a4 in print_stack_frame ()
#4  0x30300 in normal_stop ()
#5  0x2f0f0 in child_create_inferior ()
#6  0x2b770 in tty_command ()
#7  0x3940 in execute_command ()
#8  0x3af4 in execute_command ()
#9  0x3740 in main ()

                          Christoph Tietz (tietz@gmd.de or tietz@zi.gmd.dbp.de)

Newsgroups: gnu.gdb.bug
From: talvola@qin.berkeley.edu (Erik Talvola)
Subject: Build problems with GDB-3.6 under SCO ODT
Organization: /usr/users/talvola/.organization
Distribution: gnu
Date: Tue, 21 Jul 1992 14:16:55 GMT

I just pulled over gdb-4.6 to the SCO box here (ODT v1.1), and had a couple
problems building (with GCC ss-920717).

1) 2 files are greater than 14 characters.  Note that under SCO's tar at least,
   these files are not created.  They should be shortened (even though SCO does
   not need them):

   hppahpux-tdep.c
   hppahpux-xdep.c

2) It was trying to use gcc -posix as the compiler.  GCC v2.2.2 (or
    at least ss-920717) doesn't use -posix.  Take it out of mh-sco.

3) One warning:

   readline.c: 2545: warning: comparison is always 1 due to limited range of 
	data type

   I didn't bother looking at this.

4) One error:

  main.c: 523: initializer element for `long_options[0].has_arg' is not
     constant

  This happens for long_options[0..27].  I am not sure if this is a gcc
   bug or not.  I changed the definition of the has_arg element in the
   struct in getopt.h to be an enum type, which is what it is used as,
   and moved the enum definition above the struct.  This stopped the errors
   and made it compile successfully.

That's all for now - haven't tried to run it yet - just compiling.

-- Erik
--
+----------------------------+
! Erik Talvola               | "It's just what we need... a colossal negative 
! talvola@qin.berkeley.edu   | space wedgie of great power coming right at us
! ...!ucbvax!qin!talvola     | at warp speed." -- Star Drek

Newsgroups: gnu.gdb.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: GDB 4.6 is slower than molasses on large C++ programs
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 28 Jul 1992 02:21:32 GMT

GDB 4.6 is very slow when debugging large C++ problems (sparc, SunOS 4.1.2,
with GCC 2.2.2).  Most of the problems seem to be related to lookup_symbol's
disconcerting habit of sequentially demangling every symbol in the program
whenever it can't look something up.  Perhaps this behavior could be switched
off -- normally one doesn't want GDB to pause for 30 seconds simply to tell
you that you misspelled a variable.

Here's one fix that helped somewhat.  GDB internally converts expressions like
`this->f' to `$this->f'; but the `$' causes it to go through its painfully
slow sequential search for demangled symbols, because lookup_symbol thinks
`$this' is from a quoted name string.  Here's a workaround; but more work is
needed.

===================================================================
RCS file: main.c,v
retrieving revision 4.6
diff -c -r4.6 main.c
*** main.c	1992/07/14 07:34:27	4.6
--- main.c	1992/07/28 00:02:51
***************
*** 1054,1060 ****
  
  /* Variables which are necessary for fancy command line editing.  */
  char *gdb_completer_word_break_characters =
!   " \t\n!@#$%^&*()+=|~`}{[]\"';:?/>.<,-";
  
  /* When completing on command names, we remove '-' from the list of
     word break characters, since we use it in command names.  If the
--- 1054,1060 ----
  
  /* Variables which are necessary for fancy command line editing.  */
  char *gdb_completer_word_break_characters =
!   " \t\n!@#%^&*()+=|~`}{[]\"';:?/>.<,-";
  
  /* When completing on command names, we remove '-' from the list of
     word break characters, since we use it in command names.  If the
***************
*** 1062,1068 ****
     it thinks that the string needs to be quoted and automatically supplies
     a leading quote. */
  char *gdb_completer_command_word_break_characters =
!   " \t\n!@#$%^&*()+=|~`}{[]\"';:?/>.<,";
  
  /* Characters that can be used to quote completion strings.  Note that we
     can't include '"' because the gdb C parser treats such quoted sequences
--- 1062,1068 ----
     it thinks that the string needs to be quoted and automatically supplies
     a leading quote. */
  char *gdb_completer_command_word_break_characters =
!   " \t\n!@#%^&*()+=|~`}{[]\"';:?/>.<,";
  
  /* Characters that can be used to quote completion strings.  Note that we
     can't include '"' because the gdb C parser treats such quoted sequences

Newsgroups: gnu.gdb.bug
From: rogerr@netcom.com (roger reynolds)
Subject: GDB with SUN UNBUNLDED CC problems
Followup-To: poster
Keywords: GDB SUN CC
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Wed, 29 Jul 1992 19:56:36 GMT

	I am just starting to switch over from Sun's bundled compiler,
	to their unbundled compiler, and its ANSI self "acc".

	I notice that gdb can't do much with programs compiled with the 
	unbundled cc and acc compilers. Specifically, gdb core dumps
	when I try to list any subroutine.

	I have been using gdb for quite some time, and find it much better
	to use than dbx, so I am looking for some advice on what, if
	anything I need to do to get gdb to work with these new compilers.
	
	I have tried gdb versions 3.5, and 4.3 with equally bad results.
	
	I am on a Sparc 2 running SunOs 4.1.1

	Sound familiar to anybody?

	Thanks for any help,
	rogerr@netcom.com


Newsgroups: gnu.gdb.bug
From: andrew@airs.COM (Andrew Evans)
Subject: Execution trace feature for gdb
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 16:07:03 GMT

I've been using gdb 4.5 on a SCO UNIX machine for some time now.  I've
been very pleased with the evolution and development of the program.
I find gdb very useful in my work, and I have an idea which would be
valuable to me and possibly others as well.

I would like gdb to be able to provide a feature for tracing the
execution of a running program.  The output could be similar to what
you get when stepping through a program: print the source line and any
display expressions.  An abbreviated form printing just function calls
and their arguments (and return values) would be useful as well.  The
idea here is to eliminate a lot of return-pressing when tracing
execution through large portions of code.  I feel that this would make
pinpointing certain bugs much easier.

Although I'm not familiar with the gdb code, it seems to me that this
would be fairly simple to do, since most of the functionality already
exists.  Some way of automating these systems is what's needed.  I'm
hoping that some gdb expert would be able to do this without much
effort.

Thanks for a great program, and I hope you find this useful.

---
Andrew Evans - Infinity Development Systems - Waltham, MA

Newsgroups: gnu.gdb.bug
From: alan.mckay@dragon.acadiau.ca (Alan McKay)
Subject: Re: GDB 4.6 is slower than molasses on large C++ programs
Organization: Acadia University
Distribution: gnu
Date: Wed, 29 Jul 1992 13:47:13 GMT

eggert@twinsun.COM (Paul Eggert) writes:

> GDB 4.6 is slower than molasses on large C++ programs

I'm not familiar with this "molasses" program.  Could someone please
provide me with more info on it?  Is it an alternative to gdb?  Is
it freeware?  Or must I pay for it?

-- 
--
Alan W. McKay		| (902)542-2201.158	| Wolfville, N.S. Canada
alan@acadiau.ca		| Acadia University	| SUB Box 6008, B0P 1Z1
----------------------------------------- My Canada includes Quebec -----

Newsgroups: gnu.gdb.bug