bug-gdb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

(no subject)


From: Ken
Subject: (no subject)
Date: Thu, 13 Sep 2001 17:45:32 -0600

When compiling gdb-5.0 on a Dec Alpha running Tru64 UNIX OSF1 V5.1 I receive an error saying that several EF_ defines do not exist that are used in the file alpha-nat.c.  I hacked the code so it would correctly read my machine/reg.h
After this I was down to one error saying EF_SP was undefined.  In the header file I noticed this line:
#undef EF_SP                    /* r30: stack pointer (see note above) */
 
Very odd.
I installed gdb-5.0 on a similar machine running OSF1 V4.0 and had no problems and it runs fine.  So for kicks I changed it into the #define it was on V4.0.  After that the compile completed.
 
Now whenever I debug I get the following:
<output>
/usr/local/bin/gdb a.out
GNU gdb 5.0
Copyright 2000 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or 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.
This GDB was configured as "alphaev67-dec-osf5.1"...
(gdb) l
1       main()
2       {
3       int i;
4       char in[1024];
5
6       printf("Enter i: ");
7       gets(in);
8       i = atoi(in);
9       printf("Thank you!\n");
10      }
(gdb) b 6
Breakpoint 1 at 0x120001190: file test.c, line 6.
(gdb) r
Starting program: /usr/users/nelson/a.out
Error while reading shared library symbols:
Error reading symbol table: Memory exhausted
Error while reading shared library symbols:
Error reading symbol table: Memory exhausted
Error while reading shared library symbols:
Error reading symbol table: Memory exhausted
Error while reading shared library symbols:
Error reading symbol table: Memory exhausted
gdb-internal-error: virtual memory exhausted: can't allocate 8168 bytes.
An internal GDB error was detected.  This may make make further
debugging unreliable.  Continue this debugging session? (y or n) n
 
Create a core file containing the current state of GDB? (y or n) n
</ouptut>
 
There is quite a long pause between the time that I run and the errors.
Any ideas or suggestions?
 
Thanks,
Ken

reply via email to

[Prev in Thread] Current Thread [Next in Thread]