gdb under FC devel and undefined symbols

[Ralf Ertzinger]

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.

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.

[John Reiser]

>  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. 
Assuming that 'flavor' is not a macro, then this is a bug in the compiler.
A named array always resides in addressible memory, so must have a symbol
visible to the debugger if the name is in scope.  File a bug report against
gcc.  A small and simple testcase is always appreciated, but file the
report anyway, naming the exact SRPM of the source and the exact gcc version,
if a few attempts at simplifying fail.

>  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. 
Become familiar with assembly language and gdb's access to it.
For the particular case presented above (again, assuming 'flavor'
is not a macro), it isn't outrageously hard.

--

[Ralf Ertzinger]

Hi.

On Fri, 17 Feb 2006 08:38:36 -0800, John Reiser wrote:

>  Assuming that 'flavor' is not a macro, then this is a bug in
> the
>  compiler. 
flavor is a *int:

int i, *flavor, yum = 0;

>  Become familiar with assembly language and gdb's access to it.
>  For the particular case presented above (again, assuming 'flavor'
>  is not a macro), it isn't outrageously hard. 
If you'd happen to have a pointer handy I'd be most grateful.
x86 assembler is not a total stranger to me.

[John Reiser]

>  flavor is a *int:
>  
>  int i, *flavor, yum = 0; 
Because flavor is a scalar, it is often somewhat easy for the compiler
to "eliminate" it, leaving no memory location where it resides.
In many cases a register is assigned.  If for an entire statement,
then the register could be tagged as the location of the variable,
but if for less than an entire statement then it gets cloudy as to
what is reasonable.

>  x86 assembler is not a total stranger to me. 
The one-minute into is:
  (gdb) x/4i $pc  # next instruction and following 3
  (gdb) x/12i $pc-0x18  # heuristic for plausible previous instructions
  (gdb) p $eax   # register %eax
  (gdb) p $ebp   # stack frame pointer, if used as such
  (gdb) stepi   # single-step one instruction

--

[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.