[5417] in testers
Re: GCC 3.2.2
daemon@ATHENA.MIT.EDU (Omri Schwarz)
Tue May 20 18:36:21 2003
Message-Id: <200305202236.SAA15616@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:36:19 -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
> problem--have you tried using breakpoints? If so, perhaps you could
> just raise a signal instead of pause()'ing...
Another test case:
#include <unistd.h>
void foo(){
int bar = 22;
printf("baz! %d\n",bar);
pause();
}
void baz(){
foo();
}
main(){
baz();
}
And the result:
0xffffe002 in ?? ()
(gdb) where
#0 0xffffe002 in ?? ()
#1 0x0804838e in baz () at test.c:10
#2 0x080483a5 in main () at test.c:13
#3 0x420156a4 in __libc_start_main () from /lib/tls/libc.so.6
(gdb) q
The program is running. Exit anyway? (y or n) y
Also note the instruction pointer in frame 0,
which looks mighty suspicious.
