From: David Carlton <carlton@math.stanford.edu>
To: Michael Elizabeth Chastain <mec@shout.net>
Cc: gdb@sources.redhat.com, ezannoni@redhat.com, fnasser@redhat.com,
jimb@redhat.com
Subject: Re: [rfc] plans for linespec.c
Date: Wed, 08 Jan 2003 23:22:00 -0000 [thread overview]
Message-ID: <ro1ptr7ckhi.fsf@jackfruit.Stanford.EDU> (raw)
In-Reply-To: <200301080012.h080CdS01449@duracef.shout.net>
On Tue, 7 Jan 2003 18:12:39 -0600, Michael Elizabeth Chastain <mec@shout.net> 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
next prev parent reply other threads:[~2003-01-08 23:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-01-08 0:12 Michael Elizabeth Chastain
2003-01-08 23:22 ` David Carlton [this message]
-- strict thread matches above, loose matches on Subject: below --
2003-01-09 16:09 Michael Elizabeth Chastain
2003-01-09 4:24 Michael Elizabeth Chastain
2003-01-09 6:01 ` David Carlton
2003-01-09 9:45 ` Joel Brobecker
2003-01-07 22:22 David Carlton
2003-01-08 14:25 ` Elena Zannoni
2003-01-08 22:48 ` David Carlton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ro1ptr7ckhi.fsf@jackfruit.Stanford.EDU \
--to=carlton@math.stanford.edu \
--cc=ezannoni@redhat.com \
--cc=fnasser@redhat.com \
--cc=gdb@sources.redhat.com \
--cc=jimb@redhat.com \
--cc=mec@shout.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox