From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2934 invoked by alias); 14 Dec 2003 11:45:29 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 2927 invoked from network); 14 Dec 2003 11:45:28 -0000 Received: from unknown (HELO monty-python.gnu.org) (199.232.76.173) by sources.redhat.com with SMTP; 14 Dec 2003 11:45:28 -0000 Received: from [207.232.27.5] (helo=WST0054) by monty-python.gnu.org with asmtp (Exim 4.24) id 1AVVdA-0000BO-RY; Sun, 14 Dec 2003 07:45:53 -0500 Date: Sun, 14 Dec 2003 11:45:00 -0000 Message-Id: From: Eli Zaretskii To: mec.gnu@mindspring.com (Michael Elizabeth Chastain) CC: cagney@gnu.org,gdb@sources.redhat.com In-reply-to: <20031214082530.B536B4B412@berman.michael-chastain.com> (mec.gnu@mindspring.com) Subject: Re: [commit] Deprecate remaining STREQ uses Reply-to: Eli Zaretskii References: <20031214082530.B536B4B412@berman.michael-chastain.com> X-SW-Source: 2003-12/txt/msg00198.txt.bz2 > Date: Sun, 14 Dec 2003 03:25:30 -0500 (EST) > From: mec.gnu@mindspring.com (Michael Elizabeth Chastain) > > And then you will come back and say "go32 does not support running the > test suite". And then I will say: okay, fine, can you build gdb on > go32? Can you do "break main"? Can you do a backtrace? Can you print > registers? Can you print a local variable? Can you set a watchpoint? > Can you call a function with a double precision argument? > > Can you put all that in a script and post the results to gdb-testers once a > month? It should be relatively easy to produce a script like that, assuming that the tests you listed above constitute the minimal suite of tests that are required to prove that a GDB port is alive (or at least if the set of the tests required for that doesn't change too much with time). If the set of tests changes too much, tracking them might not be easy, given my free time (or should I say the lack thereof ;-)[1]. However, running the script once a month (on the then-latest snapshot, I presume) is not something that I can afford, and I don't see anyone else stepping forward to do that for me. Since your proposal for deprecating counts minor releases, would it be enough to request a run for every such release? > If nobody does those things for a platform, then I want to obsolete the > platform. I think the degree to which such a logic is justified depends on the platform. For example, x86 platforms generally benefit from Mark Kettenis's work and so are expected to bit-rot much slower than some exotic platform that shares none of the code with others. Isn't it better to start deprecating only if we know that some code specific to a platform is broken by a certain change to GDB? For example, if some interface is deprecated and no one submitted replacement code for a specific platform, then declare that platform heading into obsolescence. ----------------- Footnotes: [1] Ironically, I suggested a couple of years ago (in a message I cannot for the moment find in the archives) to add a script to the gdb/config/djgpp directory that would run GDB against some subset of the test suite, only without relying on `expect' and `dejagnu', and compare the results against the expected ones. However, both Andrew and DJ thought the idea was not worth the effort, since simple textual comparison, a-la "diff -ubBw", would bit-rot too quickly, due to changes in GDB and local library developments.