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. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
