-pg problem
hello,
can someone help me understand what is going on?
are the -p and -pg options supposed to work?
# gcc -v
Using built-in specs.
Target: i386-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada
--enable-java-awt=gtk --disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--with-cpu=generic --host=i386-redhat-linux
Thread model: posix
gcc version 4.1.1 20061011 (Red Hat 4.1.1-30)
the C fragment (from menu.c of mplayer)
#define BUF_MIN 128
#define BUF_MAX BUF_STEP*1024
int menu_init(char* cfg_file) {
char* buffer = NULL;
int bl = BUF_STEP, br = 0;
int f, fd;
#ifndef HAVE_FREETYPE
if(vo_font == NULL)
return 0;
#endif
# cc -c -I. -I.. -Wdeclaration-after-statement -march=pentium2
-mtune=pentium2 -pipe -ffast-math -ggdb -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -pthread
-I/usr/include/kde/artsc -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -o menu.o menu.c
-save-temps
cc: warning: -pipe ignored because -save-temps specified
cc: warning: -pipe ignored because -save-temps specified
# objdump -S -D menu.o -G -C -t -x | less
03a5 :
/// This will build the menu_defs list from the cfg file
#define BUF_STEP 1024
#define BUF_MIN 128
#define BUF_MAX BUF_STEP*1024
int menu_init(char* cfg_file) {
3a5: 55 push %ebp
3a6: 89 e5 mov%esp,%ebp
3a8: 83 ec 38sub$0x38,%esp
char* buffer = NULL;
3ab: c7 45 e8 00 00 00 00movl $0x0,0xffe8(%ebp)
int bl = BUF_STEP, br = 0;
3b2: c7 45 ec 00 04 00 00movl $0x400,0xffec(%ebp)
3b9: c7 45 f0 00 00 00 00movl $0x0,0xfff0(%ebp)
int f, fd;
#ifndef HAVE_FREETYPE
if(vo_font == NULL)
return 0;
#endif
now repeat above with extra "-p" flag
# cc -c -I. -I.. -Wdeclaration-after-statement -march=pentium2
-mtune=pentium2 -pipe -ffast-math -ggdb -D_LARGEFILE_SOURCE
-D_FILE_OFFSET_BITS=64 -I/usr/X11R6/include -pthread
-I/usr/include/kde/artsc -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -o menu.o menu.c
-save-temps -p
cc: warning: -pipe ignored because -save-temps specified
cc: warning: -pipe ignored because -save-temps specified
# objdump -S -D menu.o -G -C -t -x | less
/// This will build the menu_defs list from the cfg file
#define BUF_STEP 1024
#define BUF_MIN 128
#define BUF_MAX BUF_STEP*1024
int menu_init(char* cfg_file) {
3aa: 55 push %ebp
3ab: 89 e5 mov%esp,%ebp
3ad: 83 ec 38sub$0x38,%esp
3b0: e8 00 00 00 00 call 3b5
3b1: R_386_PC32 .bss
char* buffer = NULL;
3b5: c7 45 e8 00 00 00 00movl $0x0,0xffe8(%ebp)
int bl = BUF_STEP, br = 0;
3bc: c7 45 ec 00 04 00 00movl $0x400,0xffec(%ebp)
3c3: c7 45 f0 00 00 00 00movl $0x0,0xfff0(%ebp)
int f, fd;
#ifndef HAVE_FREETYPE
if(vo_font == NULL)
return 0;
#endif
now WTF is the line 3b0 ???
ideas?
----
--
Adam Sulmicki
http://www.eax.com The Supreme Headquarters of the 32 bit registers
Re: -pg problem
On Tue, 2 Jan 2007, Ian Lance Taylor wrote: Adam Sulmicki <[EMAIL PROTECTED]> writes: can someone help me understand what is going on? are the -p and -pg options supposed to work? This question is not appropriate for gcc@gcc.gnu.org, which is a mailing list for gcc developments. It is appropriate for [EMAIL PROTECTED] -p does work on GNU/Linux systems. 3b0: e8 00 00 00 00 call 3b5 3b1: R_386_PC32 .bss That is presumably the call to mcount which records the profiling information. except that : # grep mcount menu.c static int mcount = 0; -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers
Re: -pg problem
can someone help me understand what is going on? are the -p and -pg options supposed to work? This question is not appropriate for gcc@gcc.gnu.org, which is a mailing list for gcc developments. It is appropriate for [EMAIL PROTECTED] I apologize for this. -p does work on GNU/Linux systems. 3b0: e8 00 00 00 00 call 3b5 3b1: R_386_PC32 .bss That is presumably the call to mcount which records the profiling information. except that : # grep mcount menu.c static int mcount = 0; Just to wrap things up. I have renamed all occurences of "mcount" in sources to something else, and the program does not crash anymore. Thanks a lot for help! -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers
gcc, mplayer and profile (mcount)
Hello folks, This is my last post on the subject of mcount. I have spent a quite bit of time on this to find out that the results of myserious crashes is the mcount variable. (with help from Ian Lance Taylor). I have reported the issue to both gcc and mplayer lists, and from _BOTH_ lists I got reply that they do not feel it is their problem and blamed the other package. WELL, as far as I'm concerned the issue is solved, I know how to fix it and works for me. In spirit making OSS better, I took the extra effor to report findings back to both lists. In reward I got flamed on both list. The Issue: Anyway, the scop is that once I try to compile mplayer with -pg option (or -p) then it will start myseriously crash on mplayer/libmenu/menu.c:menu_init(). It comes out that in mplayer/libmenu/menu.c there's in use "mcount" variable: # grep mcount menu.c static int mcount = 0; however, once "-pg" or "-p" options are enabled, gcc uses mcount _function_ for its internal profiling. The results are mysterious crashes on menu_init(). Suggested solutions: * Rename mcount in mplayer/libmenu/menu.c to something else. * document mcount in gcc man page * gcc prints warning. * do nothing. I can immagine that gcc developers might have intentionally left mcount() visible to user space so that user can replace gcc's mcount() with their own implementation. Just FWIW, I don't care if anything will get done about it. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers
Re: gcc, mplayer and profile (mcount)
On Wed, 3 Jan 2007, Ian Lance Taylor wrote: I told you was to use the gcc-help mailing list, which was correct. So this seems to be a bug in gcc: it should be calling _mcount. It just that it is my impression that gcc list is more appropriate for gcc bugs than gcc-help. I also did my best to answer your question. In your original message you didn't mention that there was an mcount variable in your program, so it's not surprising that I wasn't able to identify the problem. Yeah, my mistake, back then I did not know that gcc used mcount() for its own purposes. On Wed, 3 Jan 2007, Andrew Haley wrote: Trivia time: what is the longest delay between a bug being committed to gcc before someone notices and a fix being committed? This one is eleven years and eight months. I wonder if we have a record. not gcc related, but here's my own record : http://www.cs.unm.edu/~sulmicki/eax/patches/xterm/xterm2.diff this bug as present in xterm ever since it ran on linux for the first time, up until 2001. No idea how long it is, but at least a decade. -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers
RE: gcc, mplayer and profile (mcount)
On Wed, 3 Jan 2007, Dave Korn wrote: Is that your idea of an apology? Regardless of topicality there's no reasonable reading of Ian's words as a flame, they were entirely polite and well-measured, and you should withdraw your baseless accusation and say sorry rather than trying to rationalise it. Fine. I am sorry, and I apoligize. Adam -- Adam Sulmicki http://www.eax.com The Supreme Headquarters of the 32 bit registers
