Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Michael Elizabeth Chastain]

First something trivial:

   likely that the variable will occure early in the core file (an
                                 ^^^^^^ typo

I checked Single Unix Spec v3 on rlimit:

  http://www.opengroup.org/onlinepubs/007904975/functions/getrlimit.html

There is an RLIMIT_AS which applies as well, so you might as well
maximize that.

I ran this on native hppa2.0w-hp-hpux11.11 on spe191.testdrive.hp.com.
This machine has a data limit of 1 gigabyte, as you can see in the log.
The gdb.log is appended.

Michael C

===

Test Run By chastain on Tue Jan 13 21:56:05 2004
Native configuration is hppa2.0w-hp-hpux11.11

		=== gdb tests ===

Schedule of variations:
    unix

Running target unix
Using /tmp/chastain/install/hppa2.0w-hp-hpux11.11/vanilla/host/dejagnu-1.4.3/share/dejagnu/baseboards/unix.exp as board description file for target.
Using /tmp/chastain/install/hppa2.0w-hp-hpux11.11/vanilla/host/dejagnu-1.4.3/share/dejagnu/config/unix.exp as generic interface file for target.
Using /house/chastain/gdb/s1/gdb/testsuite/config/unix.exp as tool-and-target-specific interface file.
Running /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.exp ...
Executing on host: gcc /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.c  -g  -lm   -o /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb/testsuite/gdb.base/bigcore    (timeout = 300)
Executing on build: mv /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb/testsuite/gdb.base/coredir.14619/core /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb/testsuite/gdb.base/bigcore.corefile    (timeout = 300)
Executing on build: rmdir /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb/testsuite/gdb.base/coredir.14619    (timeout = 300)
GNU gdb 2004-01-13-cvs
Copyright 2004 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 "hppa2.0w-hp-hpux11.11".
(gdb) set height 0
(gdb) set width 0
(gdb) dir
Reinitialize source path to empty? (y or n) y
Source directories searched: $cdir:$cwd
(gdb) dir /house/chastain/gdb/s1/gdb/testsuite/gdb.base
Source directories searched: /house/chastain/gdb/s1/gdb/testsuite/gdb.base:$cdir:$cwd
(gdb) file /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb \r/testsuite/gdb.base/bigcore
Reading symbols from /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb/testsuite/gdb.base/bigcore...done.
(gdb) set print sevenbit-strings
(gdb) PASS: gdb.base/bigcore.exp: set print sevenbit-strings; bigcore
set width 0
(gdb) PASS: gdb.base/bigcore.exp: set width 0; bigcore
delete breakpoints
(gdb) info breakpoints
No breakpoints or watchpoints.
(gdb) break main
Breakpoint 1 at 0x3230: file /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.c, line 114.
(gdb) run 
Starting program: /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb/testsuite/gdb.base/bigcore 

Breakpoint 1, main () at /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.c:114
114	  print_string ("Maximize resource limits ...\n");
(gdb) list bigcore.c:1,1
1	/* This testcase is part of GDB, the GNU debugger.
(gdb) search Dump core
179	  print_string ("Dump core ....\n");
(gdb) tbreak 179
Breakpoint 2 at 0x340c: file /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.c, line 179.
(gdb) PASS: gdb.base/bigcore.exp: tbreak 179
continue
Continuing.
Maximize resource limits ...
  core: cur=0x7ffffffe max=0x7fffffff -> cur=0x7fffffff max=0x7fffffff
  data: cur=0x40000000 max=0x40000000 -> cur=0x40000000 max=0x40000000
  stack: cur=0x8000000 max=0x8000000 -> cur=0x8000000 max=0x8000000
Alocating the entire heap ...
  536870912 bytes @ 0x40003388
  268435456 bytes @ 0x60003390
  67108864 bytes @ 0x70003398
  33554432 bytes @ 0x740033a0
  16777216 bytes @ 0x760033a8
  8388608 bytes @ 0x770033b0
  4194304 bytes @ 0x778033b8
  2097152 bytes @ 0x77c033c0
  262144 bytes @ 0x77e033c8
  32768 bytes @ 0x77e433d0
  16384 bytes @ 0x77e4b3d8
  2048 bytes @ 0x77e4f3e0
  1024 bytes @ 0x77e4fbe8
  8 bytes @ 0x77e4fff0
main () at /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.c:179
179	  print_string ("Dump core ....\n");
(gdb) PASS: gdb.base/bigcore.exp: continue
next
Dump core ....
180	  *(char*)0 = 0;
(gdb) PASS: gdb.base/bigcore.exp: next
print heap
$1 = (struct list *) 0x77e4fff0
(gdb) print $.next
$2 = (struct list *) 0x77e4fbe8
(gdb) print $.next
$3 = (struct list *) 0x77e4f3e0
(gdb) print $.next
$4 = (struct list *) 0x77e4b3d8
(gdb) print $.next
$5 = (struct list *) 0x77e433d0
(gdb) print $.next
$6 = (struct list *) 0x77e033c8
(gdb) print $.next
$7 = (struct list *) 0x77c033c0
(gdb) print $.next
$8 = (struct list *) 0x778033b8
(gdb) print $.next
$9 = (struct list *) 0x770033b0
(gdb) print $.next
$10 = (struct list *) 0x760033a8
(gdb) print $.next
$11 = (struct list *) 0x740033a0
(gdb) print $.next
$12 = (struct list *) 0x70003398
(gdb) print $.next
$13 = (struct list *) 0x60003390
(gdb) print $.next
$14 = (struct list *) 0x40003388
(gdb) print $.next
$15 = (struct list *) 0x0
(gdb) PASS: gdb.base/bigcore.exp: extract heap
core /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb \r/testsuite/gdb.base/bigcore.corefile
A program is being debugged already.  Kill it? (y or n) y
Core was generated by `bigcore'.
Program terminated with signal 10, Bus error.
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

#0  main () at /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.c:180
180	  *(char*)0 = 0;
(gdb) PASS: gdb.base/bigcore.exp: load corefile
print heap
$16 = (struct list *) 0x77fbffe0
(gdb) FAIL: gdb.base/bigcore.exp: check heap (address 0x77e4fff0)
testcase /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.exp completed in 183 seconds

		=== gdb Summary ===

# of expected passes		7
# of unexpected failures	1
Executing on host: /house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb/testsuite/../../gdb/gdb -nw --command gdb_cmd    (timeout = 300)
GNU gdb 2004-01-13-cvs
Copyright 2004 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 "hppa2.0w-hp-hpux11.11".
/house/chastain/gdb/build/hppa2.0w-hp-hpux11.11/s1-blank-gcc-none/gdb/testsuite/../../gdb/gdb version  2004-01-13-cvs -nx

runtest completed at Tue Jan 13 21:59:08 2004

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Andrew Cagney]

> First something trivial:
> 
>    likely that the variable will occure early in the core file (an
>                                  ^^^^^^ typo
> 
> I checked Single Unix Spec v3 on rlimit:
> 
>   http://www.opengroup.org/onlinepubs/007904975/functions/getrlimit.html
> 
> There is an RLIMIT_AS which applies as well, so you might as well
> maximize that.

M'kay.

> 180	  *(char*)0 = 0;
> (gdb) PASS: gdb.base/bigcore.exp: next
> print heap
> $1 = (struct list *) 0x77e4fff0

[...]

> (gdb) PASS: gdb.base/bigcore.exp: load corefile
> print heap
> $16 = (struct list *) 0x77fbffe0
> (gdb) FAIL: gdb.base/bigcore.exp: check heap (address 0x77e4fff0)

At first glance it looks like a bug in the HP/UX code, but I wonder. 
Could the startup code be allocating an extra bit of memory leading to 
that address being moved?  Might need to tweak things so that the 
program under GDB is the one that is made to dump core.

> testcase /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.exp completed in 183 seconds

Yea, contrast that to my GNU/Linux box which manages:

 > testcase src/gdb/testsuite/gdb.base/bigcore.exp completed in 4 seconds

Andrew

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Michael Elizabeth Chastain]

Another thought that might be helpful, or might not:

We could add some environment variables so that the person running
the script could enable specific scripts.  Like:

  GDB_TEST_SUITE_BIG_CORE
  GDB_TEST_SUITE_CPLUS_EXPERIMENTAL
  ...
  GDB_TEST_SUITE_EVERYTHING

The default for all of these would be "off".  After some experience
with them, we could take out the environment variable tests.

I was thinking about this for some of the refurbished C++ tests like
member-ptr.exp.  This script has lots of interesting non-PASS results
with both g++ and hpacc.  Daniel and David would benefit from it while
they are developing, but other people don't want to see all the
non-PASSes because they aren't regressions.

As Andrew likes to say ... thoughts?

Michael C

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Andrew Cagney]

> BTW, Michael, any thoughts on how to fail this on systems that can't 
>> efficiently dump a 3g core file?  Skip the test I guess, but with which 
>> mechanism?  untested?
> 
> 
> Unconditional UNTESTED is simple and good.  "Hey, what happened with
> the 3 gigabyte core dump test?"  "Oh, it says UNTESTED".  It's pretty
> clear to me what that means.
> 
> As for *how* to do it, that is harder.
> 
> The real issue is that the criterion is not really "what is the target
> triple", but "what are the resources of the specific test bed".  Like,
> Daniel J says that it would be awkward to enable it in the Debian
> version.  And it's useless for me on HP Test Drive, because I run into a
> ulimit at 1 gigabyte.  That's a property of HP-TD policy, not of the
> hppa2.0w-hp-hpux11.11 target.  I dunno how to encode that kind of
> criterion in the test suite.

Daniel, did you get to try this test?

So far the problem I've hit is with kernel's that can't write generate 
core files - they end up really trying to write write / consume gb worth 
of disk.  Fortunatly those OSs families should be easy to identify and skip.

Andrew

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Michael Elizabeth Chastain]

> BTW, Michael, any thoughts on how to fail this on systems that can't 
> efficiently dump a 3g core file?  Skip the test I guess, but with which 
> mechanism?  untested?

Unconditional UNTESTED is simple and good.  "Hey, what happened with
the 3 gigabyte core dump test?"  "Oh, it says UNTESTED".  It's pretty
clear to me what that means.

As for *how* to do it, that is harder.

The real issue is that the criterion is not really "what is the target
triple", but "what are the resources of the specific test bed".  Like,
Daniel J says that it would be awkward to enable it in the Debian
version.  And it's useless for me on HP Test Drive, because I run into a
ulimit at 1 gigabyte.  That's a property of HP-TD policy, not of the
hppa2.0w-hp-hpux11.11 target.  I dunno how to encode that kind of
criterion in the test suite.

Michael C

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Andrew Cagney]

> testcase /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.exp completed in 183 seconds
>> testcase src/gdb/testsuite/gdb.base/bigcore.exp completed in 4 seconds
> 
> 
> Figures prove: Linux dumps core faster!  :)
> 
> Part of the difference is that I'm using an NFS file system.
> But a lot of it may be sparse file support in Linux.
> 
> I can't comment on the program itself right now, maybe later.

BTW, Michael, any thoughts on how to fail this on systems that can't 
efficiently dump a 3g core file?  Skip the test I guess, but with which 
mechanism?  untested?

Andrew

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Daniel Jacobowitz]

On Thu, Jan 15, 2004 at 02:09:34PM -0500, Andrew Cagney wrote:
> >Hmm, can you think of an efficient way of soaking up most of the stack 
> >>...? :-)  On GNU/Linux, alloca() proved to be useless :-(
> >
> >
> >The best you're likely to get is recursively calling a function with a,
> >say, 4K frame.
> 
> That would unfortunatly defeat the current technique of creating a very 
> large but very sparse core file.   I'll see what I can cook up.

If you don't touch the stack at least once in a while, you will get
segfaults without first allocating stack space, on many platforms;
they'll look at how far down the stack you went and if you've moved
past the limit into data, they won't bother to grow the stack.  I'm not
sure it's possible to get stack pages allocated that aren't backed by
allocated memory...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Andrew Cagney]

> Hmm, can you think of an efficient way of soaking up most of the stack 
>> ...? :-)  On GNU/Linux, alloca() proved to be useless :-(
> 
> 
> The best you're likely to get is recursively calling a function with a,
> say, 4K frame.

That would unfortunatly defeat the current technique of creating a very 
large but very sparse core file.   I'll see what I can cook up.

Andrew

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Daniel Jacobowitz]

On Wed, Jan 14, 2004 at 10:38:31AM -0500, Andrew Cagney wrote:
> >
> >There are two things that make me really nervous about this test.  One
> >of them is systems with bad out-of-memory behavior, and the other is
> >systems that don't dump sparse corefiles.  That's some serious pounding
> >we'll be handing out...
> 
> Wicked.  Our testsuite could do with some serious real world pounding. 
> Otherwize we'll never find, fix and then maintain the edge cases those 
> tests can identify.

Well, my point is not that it will be pounding GDB, but that it will be
pounding the equipment used to test GDB; that's less obviously good :)

> BTW, I wrote:
> 
> > on some systems may not be so efficient at dumping core files making 
> the test too slow
> 
> and those systems may find it better to disable the test :-/

My fear is that it will vary by machine and configuration, not by OS.
I'll give it a shot first, but I may be asked by the maintainers of the
Debian autobuilder network to disable this test - normally I collect
test results from every architecture (that works reasonably well, I'd
been leaving off Sparc for 6.0...) when the package is built.

It's not a big deal for the FSF tree either way.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Andrew Cagney]

> 
> There are two things that make me really nervous about this test.  One
> of them is systems with bad out-of-memory behavior, and the other is
> systems that don't dump sparse corefiles.  That's some serious pounding
> we'll be handing out...

Wicked.  Our testsuite could do with some serious real world pounding. 
Otherwize we'll never find, fix and then maintain the edge cases those 
tests can identify.

BTW, I wrote:

 > on some systems may not be so efficient at dumping core files making 
the test too slow

and those systems may find it better to disable the test :-/

Andrew

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Daniel Jacobowitz]

On Wed, Jan 14, 2004 at 10:07:53AM -0500, Andrew Cagney wrote:
> >>testcase /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.exp 
> >>completed in 183 seconds
> >>testcase src/gdb/testsuite/gdb.base/bigcore.exp completed in 4 seconds
> >
> >
> >Figures prove: Linux dumps core faster!  :)
> >
> >Part of the difference is that I'm using an NFS file system.
> 
> Nope.  I'm using NFS on a weasly little 450mhz P2.
> 
> >But a lot of it may be sparse file support in Linux.
> 
> Yep.  While sparse file support is a standard part of UFS, it appears 
> that only the Linux Kernel thought to exploit it when writing the core file!

There are two things that make me really nervous about this test.  One
of them is systems with bad out-of-memory behavior, and the other is
systems that don't dump sparse corefiles.  That's some serious pounding
we'll be handing out...

Also, you will get very different results even on GNU/Linux depending
on your kernel's overcommit behavior.  It may refuse to allocate more
VM space than you have RAM if strict overcommit mode is enabled.

On a minor note, your test for the maximum value of a size_t is
unportable.  C does not define signed overflow, so a future version of
GCC (possibly 3.4 or even 3.3 already, I don't know) can assume that
the loop never terminates and remove the rest of the program as
unreachable.  I doubt it'll do that when not optimizing.

> >I can't comment on the program itself right now, maybe later.
> 
> Hmm, can you think of an efficient way of soaking up most of the stack 
> ...? :-)  On GNU/Linux, alloca() proved to be useless :-(

The best you're likely to get is recursively calling a function with a,
say, 4K frame.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Andrew Cagney]

>> testcase /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.exp completed in 183 seconds
>> testcase src/gdb/testsuite/gdb.base/bigcore.exp completed in 4 seconds
> 
> 
> Figures prove: Linux dumps core faster!  :)
> 
> Part of the difference is that I'm using an NFS file system.

Nope.  I'm using NFS on a weasly little 450mhz P2.

> But a lot of it may be sparse file support in Linux.

Yep.  While sparse file support is a standard part of UFS, it appears 
that only the Linux Kernel thought to exploit it when writing the core file!

> I can't comment on the program itself right now, maybe later.

Hmm, can you think of an efficient way of soaking up most of the stack 
...? :-)  On GNU/Linux, alloca() proved to be useless :-(

Andrew

Re: [patch/rfc/testsuite] Test GDB on not-so-little core files

[Michael Elizabeth Chastain]

> testcase /house/chastain/gdb/s1/gdb/testsuite/gdb.base/bigcore.exp completed in 183 seconds
> testcase src/gdb/testsuite/gdb.base/bigcore.exp completed in 4 seconds

Figures prove: Linux dumps core faster!  :)

Part of the difference is that I'm using an NFS file system.
But a lot of it may be sparse file support in Linux.

I can't comment on the program itself right now, maybe later.

Michael C

[patch/rfc/testsuite] Test GDB on not-so-little core files

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

Hello,

This test:

- runs a program that allocates a bit of memory
- lets the program dump core
- compares the corefile against a a running version of the program

On my i386 GNU/Linux system I'm seeing the failure:

> KFAIL: gdb.base/bigcore.exp: check heap (address 0xb7449008) (PRMS: gdb/1509)
> 
>                 === gdb Summary ===
> 
> # of expected passes            7
> # of known failures             1

from:

> (gdb) print $.next
> $55 = (struct list *) 0x400c0490
> (gdb) print $.next
> $56 = (struct list *) 0xbffc6008
> (gdb) print $.next
> Error accessing memory address 0xbffc6008: Invalid argument.
> (gdb) KFAIL: gdb.base/bigcore.exp: check heap (address 0xb7449008) (PRMS: gdb/15

which I suspect is due to the core file being a little big:

$ du -b bigcore.corefile
282624  bigcore.corefile
$ ls -l bigcore.corefile
-rw-------    1 cagney   cagney   3084910592 Jan 13 21:21 bigcore.corefile

and gdb having difficulty accessing the 2nd gb.

Given that people might want a bit of time to digest this (on some 
systems may not be so efficient at dumping core files making the test 
too slow) I'll follow this up in a week.

enjoy,
Andrew

[-- Attachment #2: diffs --]
[-- Type: text/plain, Size: 10443 bytes --]

2004-01-13  Andrew Cagney  <cagney@redhat.com>

	* gdb.base/bigcore.exp: New file.
	* gdb.base/bigcore.c: New file.

Index: gdb.base/bigcore.c
===================================================================
RCS file: gdb.base/bigcore.c
diff -N gdb.base/bigcore.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gdb.base/bigcore.c	14 Jan 2004 02:21:36 -0000
@@ -0,0 +1,181 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+   Copyright 2004 Free Software Foundation, Inc.
+
+   This program is free software; you can redistribute it and/or modify
+   it under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 2 of the License, or
+   (at your option) any later version.
+
+   This program is distributed in the hope that it will be useful,
+   but WITHOUT ANY WARRANTY; without even the implied warranty of
+   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+   GNU General Public License for more details.
+ 
+   You should have received a copy of the GNU General Public License
+   along with this program; if not, write to the Free Software
+   Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+   Please email any bugs, comments, and/or additions to this file to:
+   bug-gdb@prep.ai.mit.edu  */
+
+#include <unistd.h>
+#include <stdlib.h>
+#include <sys/resource.h>
+
+/* Print routines:
+
+   The following are so that printf et.al. can be avoided.  Those
+   might try to use malloc() and that, for this code, would be a
+   disaster.  */
+
+#define printf do not use
+
+const char digit[] = "0123456789abcdefghijklmnopqrstuvwxyz";
+
+static void
+print_char (char c)
+{
+  write (1, &c, sizeof (c));
+}
+
+static void
+print_unsigned (unsigned long u)
+{
+  if (u >= 10)
+    print_unsigned (u / 10);
+  print_char (digit[u % 10]);
+}
+
+static void
+print_hex (unsigned long u)
+{
+  if (u >= 16)
+    print_hex (u / 16);
+  print_char (digit[u % 16]);
+}
+
+static void
+print_string (const char *s)
+{
+  for (; (*s) != '\0'; s++)
+    print_char ((*s));
+}
+
+/* Print the current values of RESOURCE.  */
+
+static void
+print_rlimit (int resource)
+{
+  struct rlimit rl;
+  getrlimit (resource, &rl);
+  print_string ("cur=0x");
+  print_hex (rl.rlim_cur);
+  print_string (" max=0x");
+  print_hex (rl.rlim_max);
+}
+
+static void
+maximize_rlimit (int resource, const char *prefix)
+{
+  struct rlimit rl;
+  print_string ("  ");
+  print_string (prefix);
+  print_string (": ");
+  print_rlimit (resource);
+  getrlimit (resource, &rl);
+  rl.rlim_cur = rl.rlim_max;
+  setrlimit (resource, &rl);
+  print_string (" -> ");
+  print_rlimit (resource);
+  print_string ("\n");
+}
+
+struct list
+{
+  struct list *next;
+  size_t size;
+};
+
+/* Put the "heap" pointer in the BSS section.  That way it is more
+   likely that the variable will occure early in the core file (an
+   address before the heap) and hence more likely that GDB will at
+   least get its value right.  */
+
+static struct list *heap;
+
+int
+main ()
+{
+
+  /* Try to expand all the resource limits beyond the point of sanity
+     - we're after the biggest possible core file.  */
+
+  print_string ("Maximize resource limits ...\n");
+#ifdef RLIMIT_CORE
+  maximize_rlimit (RLIMIT_CORE, "core");
+#endif
+#ifdef RLIMIT_DATA
+  maximize_rlimit (RLIMIT_DATA, "data");
+#endif
+#ifdef RLIMIT_STACK
+  maximize_rlimit (RLIMIT_STACK, "stack");
+#endif
+
+  /* Allocate as much memory as possible creating a linked list of
+     each section.  The linking ensures that some, but not all, the
+     memory is allocated.  NB: Some kernels handle this efficiently -
+     only allocating and writing out referenced pages leaving holes in
+     the file for unreferend pages - while others handle this poorly -
+     writing out all pages including those that wern't referenced.  */
+
+  print_string ("Alocating the entire heap ...\n");
+  {
+    size_t chunk_size;
+
+    /* Compute the largest power-of-two value that fits in chunk_size.  */
+    {
+      size_t tmp;
+      for (tmp = 1; tmp > 0; tmp <<= 1)
+	chunk_size = tmp;
+    }
+
+    /* Create a linked list of memory chunks.  Start with CHUNK_SIZE
+       blocks of memory and then try allocating smaller and smaller
+       amounts until all (well at least most) memory has been
+       allocated.  */
+    heap = NULL;
+    while (chunk_size >= sizeof (struct list))
+      {
+	while (1)
+	  {
+	    struct list *chunk = malloc (chunk_size);
+	    if (chunk == NULL)
+	      {
+		if (heap != NULL && heap->size == chunk_size)
+		  print_string ("\n");
+		break;
+	      }
+	    if (heap == NULL || heap->size != chunk_size)
+	      {
+		print_string ("  ");
+		print_unsigned (chunk_size);
+		print_string (" bytes @ ");
+	      }
+	    else
+	      print_string (", ");
+	    chunk->size = chunk_size;
+	    chunk->next = heap;
+	    print_string ("0x");
+	    print_hex ((unsigned long) chunk);
+	    heap = chunk;
+	  }
+	chunk_size >>= 1;
+      }
+  }
+
+  /* Push everything out to disk.  */
+
+  print_string ("Dump core ....\n");
+  *(char*)0 = 0;
+}
Index: gdb.base/bigcore.exp
===================================================================
RCS file: gdb.base/bigcore.exp
diff -N gdb.base/bigcore.exp
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gdb.base/bigcore.exp	14 Jan 2004 02:21:36 -0000
@@ -0,0 +1,172 @@
+# Copyright 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2004
+# Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 2 of the License, or
+# (at your option) any later version.
+# 
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+# 
+# You should have received a copy of the GNU General Public License
+# along with this program; if not, write to the Free Software
+# Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+
+# Please email any bugs, comments, and/or additions to this file to:
+# bug-gdb@prep.ai.mit.edu
+
+# This file is based on corefile.exp which was written by Fred
+# Fish. (fnf@cygnus.com)
+
+if $tracelevel then {
+	strace $tracelevel
+}
+
+set prms_id 0
+set bug_id 0
+
+# are we on a target board
+if ![isnative] then {
+    return
+}
+
+set testfile "bigcore"
+set srcfile ${testfile}.c
+set binfile ${objdir}/${subdir}/${testfile}
+set corefile ${objdir}/${subdir}/${testfile}.corefile
+
+if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug}] != "" } {
+     gdb_suppress_entire_file "Testcase compile failed, so all tests in this file will automatically fail."
+}
+
+# Create a core file named "TESTFILE.corefile" rather than just
+# "core", to avoid problems with sys admin types that like to
+# regularly prune all files named "core" from the system.
+
+# Some systems append "core" to the name of the program; others append
+# the name of the program to "core"; still others (like Linux, as of
+# May 2003) create cores named "core.PID".  In the latter case, we
+# could have many core files lying around, and it may be difficult to
+# tell which one is ours, so let's run the program in a subdirectory.
+
+set found 0
+set coredir "${objdir}/${subdir}/coredir.[getpid]"
+file mkdir $coredir
+catch "system \"(cd ${coredir}; ${binfile}; true) >/dev/null 2>&1\""
+set names [glob -nocomplain -directory $coredir *core*]
+if {[llength $names] == 1} {
+    set file [file join $coredir [lindex $names 0]]
+    remote_exec build "mv $file $corefile"
+    set found 1
+}
+
+# Try to clean up after ourselves. 
+remote_file build delete [file join $coredir coremmap.data]
+remote_exec build "rmdir $coredir"
+    
+if { $found == 0  } {
+    warning "can't generate a core file - core tests suppressed - check ulimit -c"
+    return 0
+}
+
+# Run GDB on the bigcore program up-to where it will dump core.
+
+gdb_exit
+gdb_start
+gdb_reinitialize_dir $srcdir/$subdir
+gdb_load ${binfile}
+gdb_test "set print sevenbit-strings" "" \
+	"set print sevenbit-strings; ${testfile}"
+gdb_test "set width 0" "" \
+	"set width 0; ${testfile}"
+if { ![runto_main] } then {
+    gdb_suppress_tests;
+}
+set print_core_line [gdb_get_line_number "Dump core"]
+gdb_test "tbreak $print_core_line"
+gdb_test continue ".*print_string.*"
+gdb_test next ".*0 = 0.*"
+
+# Traverse bigcore's linked list, saving each chunk's address.  I
+# don't know why but expect_out didn't work with gdb_test_multiple.
+
+set heap ""
+set test "extract heap"
+set lim 0
+send_gdb "print heap\n"
+gdb_expect {
+    -re " = \\(struct list \\*\\) 0x0.*$gdb_prompt $" {
+	pass "$test"
+    }
+    -re " = \\(struct list \\*\\) (0x\[0-9a-f\]*).*$gdb_prompt $" {
+	set heap [concat $heap $expect_out(1,string)]
+	if { $lim > 100 } {
+	    fail "$test (limit $lim exceeded)"
+	} else {
+	    incr lim
+	    send_gdb "print $.next\n"
+	    exp_continue
+	}
+    }
+    -re ".*$gdb_prompt $" {
+	fail "$test (entry $lim)"
+    }
+    timeout {
+	fail "$test (timeout)"
+    }
+}
+
+# Now load up that core file
+
+set test "load corefile"
+gdb_test_multiple "core $corefile" "$test" {
+    -re "A program is being debugged already.  Kill it. .y or n. " {
+	send_gdb "y\n"
+	exp_continue
+    }
+    -re "Core was generated by.*$gdb_prompt $" {
+	pass "$test"
+    }
+}
+
+# Finally, re-traverse bigcore's linked list, checking each chunk's
+# address against the executable.  Don't use gdb_test_multiple as want
+# only one pass/fail.
+
+set test "check heap"
+set lim 0
+set ok 1
+send_gdb "print heap\n"
+while { $ok } {
+    gdb_expect {
+	-re " = \\(struct list \\*\\) 0x0.*$gdb_prompt $" {
+	    set ok 0
+	    if { $lim == [length $heap] } {
+		pass "$test"
+	    } else {
+		fail "$test (short list)"
+	    }
+	}
+	-re " = \\(struct list \\*\\) [lindex $heap $lim].*$gdb_prompt $" {
+	    incr lim
+	    if { $lim > 100 } {
+		set ok 0
+		fail "$test (limit $lim exceeded)"
+	    } else {
+		send_gdb "print \$.next\n"
+	    }
+	}
+	-re ".*$gdb_prompt $" {
+	    set ok 0
+	    setup_kfail i*86-*-linux* gdb/1509
+	    fail "$test (address [lindex $heap $lim])"
+	}
+	timeout {
+	    set ok 0
+	    fail "$test (timeout)"
+	}
+    }
+}