Ralf Ertzinger writes:
Hi.
I have noticed that under FC versions since FC4 the compiler seems to have
gotten more aggressive with optimizations. This shows up in the following
phenomenon (while debugging a "mount" segfault):
(gdb) run -t nfs -o ro 172.17.128.141:/var/spool/asterisk /mnt
Starting program: /bin/mount -t nfs -o ro 172.17.128.141:/var/spool/asterisk /mnt
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xd34000
Program received signal SIGSEGV, Segmentation fault.
nfsmount (spec=0x92e1200 "172.17.128.141:/var/spool/asterisk", node=0x92e1228
"/mnt", flags=0xbfd7ec20, extra_opts=0xbfd7ec1c, mount_opts=0xbfd7ec18,
nfs_mount_vers=0xbfd7ec10, running_bg=0) at nfsmount.c:1206
1206 if (flavor[i] == data.pseudoflavor)
(gdb) whatis flavor
No symbol "flavor" in current context.
This has happened to me on other occassions as well. Some asking on
#fedora-devel and googling shows that this is most likely due to
optimization in the compiler.
It's possible. It all depends on what `flavor' is. If it's a
statically allocated variable of array or pointer type there should be
debuginfo for it. If it's an auto variable gcc might have optimized
it away altogether.
While this is all good and well I'd like to know how I am to
debug
failures like the above in the future when gdb is unable to show me
variable types or contents.
Well, the point of gcc's optimizer is to make your code faster by
removing or replacing things. In this case, gcc has probably decided
that `flavor' isn't needed. For example, it may have replaced the
array indexing with some more efficient operation.
See gcc manual, Section 3.10:
Turning on optimization flags makes the compiler attempt to improve
the performance and/or code size at the expense of compilation time and
possibly the ability to debug the program.
Andrew.