From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24118 invoked by alias); 8 Jan 2003 23:22:35 -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 24109 invoked from network); 8 Jan 2003 23:22:29 -0000 Received: from unknown (HELO jackfruit.Stanford.EDU) (171.64.38.136) by 209.249.29.67 with SMTP; 8 Jan 2003 23:22:29 -0000 Received: (from carlton@localhost) by jackfruit.Stanford.EDU (8.11.6/8.11.6) id h08N3bB14289; Wed, 8 Jan 2003 15:03:37 -0800 X-Authentication-Warning: jackfruit.Stanford.EDU: carlton set sender to carlton@math.stanford.edu using -f To: Michael Elizabeth Chastain Cc: gdb@sources.redhat.com, ezannoni@redhat.com, fnasser@redhat.com, jimb@redhat.com Subject: Re: [rfc] plans for linespec.c References: <200301080012.h080CdS01449@duracef.shout.net> From: David Carlton Date: Wed, 08 Jan 2003 23:22:00 -0000 In-Reply-To: <200301080012.h080CdS01449@duracef.shout.net> Message-ID: User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.4 (Common Lisp) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2003-01/txt/msg00100.txt.bz2 On Tue, 7 Jan 2003 18:12:39 -0600, Michael Elizabeth Chastain said: > Would it be reasonable for you to double your testing and test > stabs+ as well as dwarf-2? > I'm not worried about gcc 2.95.3, gcc HEAD, and so on, because > eventually my dragnet catches that stuff and I feed it back. But > there are enough differences between dwarf-2 and stabs+ that I would > be more comfortable if you tested with both before committing > symbol-manipulation patches. Let me give you some more background to the patches that I've been doing to linespec.c: they're really simple, almost exclusively consisting of taking an existing coherent chunk of code and extracting it as a separate function. I try very hard not to change the flow of execution at all (or only in ways that are trivially correct); while some patches will come eventually that do change the flow of execution somewhat, they'll be more in the nature of tweaking the order in which stages of parsing happen, rather than anything that gets too close to symbol manipulation. So, while it's certainly necessary for me to run the test suite to make sure that I haven't screwed up (after all, I did screw up sometimes when I initially did this work; it would be nice if there were automated tools to handle some of this, but never mind that), I'm not sure that your level of concern is warranted. My machine is old, so it would turn a 10-minute testing process into a 20-minute testing process; I'm happy to do that if you think it's important, but I'm not sure that it is in this particular instance. (I am, however, worried about problems that the test suite might not catch at all: it would be nice if somebody were to make sure that the testsuite systematically tested everything that decode_line_1 does. But that's another issue entirely.) Does that help? If you still have concerns, let me know why and I'll be happy to talk further. David Carlton carlton@math.stanford.edu