[5416] in testers
Re: GCC 3.2.2
daemon@ATHENA.MIT.EDU (Omri Schwarz)
Tue May 20 18:30:35 2003
Message-Id: <200305202230.SAA15516@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:18:17 EDT."
<200305202218.SAA08037@multics.mit.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 May 2003 18:30:31 -0400
From: Omri Schwarz <ocschwar@MIT.EDU>
> > The something that is wrong is the lack of proper debugging symbols
> > for the foo() function.
> >
> > I ran into this in a much more complicated case (my
> > big blob of C code) where I could not use pause() to create
> > points for catching the process with GDB because I could
> > not get a full stack frame. The call to pause() and the calling
> > function would both be lost.
>
> 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".
> 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()?
