This is the mail archive of the
mailing list for the GDB project.
Re: [patch/rfc/testsuite] Test GDB on not-so-little core files
- From: Andrew Cagney <cagney at gnu dot org>
- To: Michael Elizabeth Chastain <mec dot gnu at mindspring dot com>,Daniel Jacobowitz <drow at mvista dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Wed, 21 Jan 2004 00:23:24 -0500
- Subject: Re: [patch/rfc/testsuite] Test GDB on not-so-little core files
- References: <20040121044245.A9C6A4B359@berman.michael-chastain.com>
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
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.