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

[Daniel Jacobowitz <drow@mvista.com>]

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