[5419] in testers
Re: GCC 3.2.2
daemon@ATHENA.MIT.EDU (Omri Schwarz)
Tue May 20 18:59:04 2003
Message-Id: <200305202259.SAA15798@alice-whacker.mit.edu>
To: Kev <klmitch@MIT.EDU>
cc: Omri Schwarz <ocschwar@MIT.EDU>, testers@MIT.EDU, ocschwar@MIT.EDU
In-Reply-To: Your message of "Tue, 20 May 2003 18:44:25 EDT."
<200305202244.SAA08379@multics.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 May 2003 18:59:02 -0400
From: Omri Schwarz <ocschwar@MIT.EDU>
> > > Ah, ok. Hmmm...weird. If I didn't know better, I'd guess that gcc
> > > optimized the call away into a direct call to pause()--but is that
> > > what's happening in your bigger blob of code? As for your original
> >
> > Yes. And we're talking about a blob of code where
> > foo() is about 100 lines with for loops galore.
> > No excuse for that.
> >
> > And optimizing our test case is also unacceptable.
> > I compiled that with "-g", not "-O".
>
> Oh, I agree completely, and the gcc developers need to be told about
> this one.
I'm composing a message to gcc-bugs@gnu.org.
A look at their page indicates that the
3.2 tree is already closed, so they might tell
us to go straight to 3.3.3 (do not collect $200)..
> > > problem--have you tried using breakpoints? If so, perhaps you could
> > > just raise a signal instead of pause()'ing...
> >
> > And do what in the signal handler? Call pause()?
>
> Ignore the signal (SIG_IGN). You raise the signal where you want to
> stop, and assuming you've got it running under gdb, gdb will break and
> let you do whatever you want. If you're not running it under gdb, you
> can just raise SIGSTOP, which will suspend the program, and you can
> then attach gdb, play around, and SIGCONT to make it continue.
>
> I don't understand why you aren't using breakpoints, though...you can
> break on any line of a given source file, function entry points, etc.
Yeah, I changed the pause() calls to raise(SIGSTOP)
and moved onwards.
