[MPlayer-users] does debug compile affect performance?

zimon@iki.fi zimon at niksula.hut.fi
Sat Sep 6 17:29:50 CEST 2003


On Sat, Sep 06, 2003 at 03:58:57PM +0200, Magnus Damm wrote:
> > In other words, there may be small slowdowns when using --enable-debug.
> > With =2 or =3 only size increases and more debug information is added,
> > speed should remain the same.
> 
> OTOH, larger binary results in a larger cache footprint.
> And larger cache footprint might lead to slowdowns.
> But all that depends on CPU type and memory bandwidth.

With rpm >= v 4.2 you can get both.
It will build two binary packages, mplayer and mplayer-debuginfo.
mplayer rpm-package will have all debug info stripped off and the binary
is alot smaller. The mplayer-debuginfo then has all debug included, if 
while building the rpm spec file had --enable-debug=3

This is really nice as you can have small binary for normal use, and then
if it sometimes crashes, you still can get all debugging information
included. I don't know if the product use binary in /usr/bin/ could
be get even smaller without --enable-debug, but at least on file sizes
I haven't noticed much difference.

-rwxr-xr-x    1 root     root      4878636 Sep  3 05:50 /usr/bin/mplayer

Then when one finds it crashes, you start gdb normally either attaching it to
the running process id or starting mplayer under gdb:

$ gdb mplayer
(gdb) add-symbol-file /usr/lib/debug/usr/bin/mplayer.debug
Reading symbols from /usr/lib/debug/usr/bin/mplayer.debug...done.
(gdb) directory /usr/src/debug/MPlayer-20030824/
Source directories searched: /usr/src/debug/MPlayer-20030824:$cdir:$cwd
(gdb) run -v /tmp/test.avi
....
Program received signal SIGSEGV, Segmentation fault.
(gdb) bt
....
and you will see even the source code of the place where the crash occured.

If you do not use rpmbuild (rpm), then I think (haven't tested) you will
get the same result by doing these steps after you have compiled the binary
with --enable-debug
$ cp mplayer mplayer.debug
$ strip mplayer
...and then installing the two binaries somewhere in /usr/local
Also if you want to be able to see source code in gdb, you have to save
the source tree (*.c and *.h files) to some place to be pointed to gdb
later.

See example of actual debugging in
"Subject: WMV videos (all?) crash on my system, MPlayer CVS 2003.08.24"
from the mail archives of this mailing list.

P.S. (there was no S!?)
I think gcc will anyway make ELF binary such a way, that on smart OSs (like
Linux) dynamic linker will not actually read debug info sections from the
binary file to the virtual memory until they are really needed. gcc, I think,
will put all debugging info to separare sections in a binary ELF file.
Some gcc/ELF/Linux expert may know more.



More information about the MPlayer-users mailing list