[5418] in testers
Re: GCC 3.2.2
daemon@ATHENA.MIT.EDU (Kev)
Tue May 20 18:44:27 2003
Message-Id: <200305202244.SAA08379@multics.mit.edu>
To: Omri Schwarz <ocschwar@MIT.EDU>
cc: Kev <klmitch@MIT.EDU>, testers@MIT.EDU
In-Reply-To: Your message of "Tue, 20 May 2003 18:30:31 EDT."
<200305202230.SAA15516@alice-whacker.mit.edu>
Date: Tue, 20 May 2003 18:44:25 -0400
From: Kev <klmitch@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.
> > 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.
--
Kevin L. Mitchell <klmitch@mit.edu>
