gdb under FC devel and undefined symbols

[Andrew Haley]

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.