gdb @7.9.1_0: cannot determine type of primitive global variables

[rbdavis (Roger Davis)]

Hi all,

I am having problems with gdb being unable to recognize the type of primitive global variables within an executable compiled from multiple source files under MacOS Yosemite 10.10.4 and Xcode 6.4 (6E35b). The same problem occurs whether I compile with either /usr/bin/cc or /usr/bin/gcc, both of which appear to be using Apple LLVM version 6.1.0 (clang-602.0.53) based on LLVM 3.6.0svn. (I have not tried with a self-built gcc compiled from gcc source.) I first noticed this a few days ago after a MacPorts update which installed gdb 7.9.1, but the same problem occurred when I deactivated MacPorts gdb 7.9.1 and reverted to MacPorts gdb 7.7.1. I also tried building gdb 7.7.1 from GNU source and still get the same problem. (Curiously, I am fairly sure that this problem did not exist with MacPorts gdb 7.7.1 before I upgraded Xcode from 6.3 to 6.4, but I upgraded gdb at the same time from 7.7.1 to 7.9.1 and so cannot be certain of exactly what triggered this bug.)

This problem is *not* exhibited by the current MacPorts gdb-apple port, but since (i) gdb-apple is based on a relatively old gdb revision (6.3) and thus possibly of questionable future lifespan, and (ii) it seems pointless to have a 'standard' (i.e., 7.9.1) gdb port that does not work, I am very ardently hoping that this issue will be addressed in the gdb 7.9.1 port.

You can reproduce this bug by creating the following two files m0.c and m1.c:

% cat m0.c
#include <stdio.h>
float gf;
extern void func();
int main() {
        gf= 1.23;
        printf("gf: %4.2f\n", gf);
        func();
}

% cat m1.c
#include <stdio.h>
extern float gf;
void func() {
        float lf;
        lf= 4.56;
        printf("lf: %4.2f\n", lf);
}

Then compile as follows:

% cc -g -c m0.c -o m0.o
% cc -g -c m1.c -o m1.o
% cc -g -o m m0.o m1.o

When you debug with MacPorts gdb 7.9.1, the type of the global float gf is unknown to gdb from within main():

% ggdb m
GNU gdb (GDB) 7.9.1
...
This GDB was configured as "x86_64-apple-darwin14.3.0".
...
Reading symbols from m...done.
(gdb) break main
Breakpoint 1 at 0x100000eee: file m0.c, line 5.
(gdb) break func
Breakpoint 2 at 0x100000f27: file m1.c, line 5.
(gdb) run
Starting program: /private/tmp/m
warning: `/BinaryCache/coreTLS/coreTLS-35.30.2~2/Objects/coretls.build/coretls.build/Objects-normal/x86_64/system_coretls_vers.o': can't open to read symbols: No such file or directory.
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.30.2~2/Symbols/BuiltProducts/libcoretls_ciphersuites.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.30.2~2/Symbols/BuiltProducts/libcoretls_handshake.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.30.2~2/Symbols/BuiltProducts/libcoretls_record.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.30.2~2/Symbols/BuiltProducts/libcoretls_stream_parser.a"
Breakpoint 1, main () at m0.c:5
5               gf= 1.23;
(gdb) s
6               printf("gf: %4.2f\n", gf);
(gdb) s
gf: 1.23
7               func();
(gdb) ptype gf
type = <data variable, no debug info>
(gdb) print gf
$1 = 1067282596

However, the type of local float lf within func is known:

(gdb) continue
Continuing.
Breakpoint 2, func () at m1.c:5
5               lf= 4.56;
(gdb) s
6               printf("lf: %4.2f\n", lf);
(gdb) s
lf: 4.56
7       }
(gdb) ptype lf
type = float
(gdb) print lf
$2 = 4.55999994

The type of the global float gf is also unknown to gdb from within func():

(gdb) ptype gf
type = <data variable, no debug info>
(gdb) print gf
$3 = 1067282596

If instead you combine the two files m[01].c into the single file s.c with the contents

#include <stdio.h>
float gf;
int main() {
        void func();
        gf= 1.23;
        printf("gf: %4.2f\n", gf);
        func();
}

void func() {
        float lf;
        lf= 4.56;
        printf("lf: %4.2f\n", lf);
}

and compile with

% cc -o s -g s.c

then gdb works perfectly well, recognizing the type of gf and correctly printing its floating point value within either main() or func().

Naturally, the actual program I am having a problem with is much larger and really needs to be in multiple files, but I think this example shows the problem about as succinctly as possible. The problem is not limited to float variables -- a global int variable shows the same problem of unknown type.

I have noticed that when I compile the above single-file s.c code, a directory s.dSYM is created. This is supposedly done when a dsymutil symbol utility is implictly run by cc. I have read that dsymutil is *not* run when the source files are separately compiled into .o files and the latter are then linked with a separate command (as in my multi-file cc command sequence shown above). Perhaps this has some bearing on the problem?

Please note also all of the references in the gdb output above to the various missing files "/BinaryCache/coreTLS/..." when gdb first starts the executable. There is no /BinaryCache directory on my system, and as these errors seem to be related to symbol issues I wonder if this is connected to the global variable type recognition problem.

Thanks,

Roger Davis

[larryv (Lawrence Velázquez)]

Thanks for the report. In future tickets, please use WikiFormatting. You also do not have to Cc “openmaintainer”, as that is a dummy address.

[stuartwesterman (Stuart Westerman)]

When you compile in the way that you have above, the debug symbols are not created.

I think you say it the best here:

I have read that dsymutil is *not* run when the source files are separately compiled into .o files and the latter are then linked with a separate command (as in my multi-file cc command sequence shown above). Perhaps this has some bearing on the problem?

Simply run dsymutil on your output elf, after linking.

The following works for me:

wei@r [gdbtest]$ cc -g -c m0.c -o m0.o; cc -g -c m1.c -o m1.o; cc -g m*.o -o m
wei@r [gdbtest]$ ls -la
total 56
drwxr-xr-x  7 wei  staff   238B Jul 12 17:21 ./
drwxr-xr-x  8 wei  staff   272B Jul 12 16:13 ../
-rwxr-xr-x  1 wei  staff   8.7K Jul 12 17:21 m*
-rw-r--r--  1 wei  staff   118B Jul 12 16:17 m0.c
-rw-r--r--  1 wei  staff   2.4K Jul 12 17:21 m0.o
-rw-r--r--  1 wei  staff   106B Jul 12 16:13 m1.c
-rw-r--r--  1 wei  staff   2.3K Jul 12 17:21 m1.o
wei@r [gdbtest]$ dsymutil m
wei@r [gdbtest]$ ls -la
total 56
drwxr-xr-x  8 wei  staff   272B Jul 12 17:21 ./
drwxr-xr-x  8 wei  staff   272B Jul 12 16:13 ../
-rwxr-xr-x  1 wei  staff   8.7K Jul 12 17:21 m*
drwxr-xr-x  3 wei  staff   102B Jul 12 17:21 m.dSYM/
-rw-r--r--  1 wei  staff   118B Jul 12 16:17 m0.c
-rw-r--r--  1 wei  staff   2.4K Jul 12 17:21 m0.o
-rw-r--r--  1 wei  staff   106B Jul 12 16:13 m1.c
-rw-r--r--  1 wei  staff   2.3K Jul 12 17:21 m1.o
wei@r [gdbtest]$ ggdb m
GNU gdb (GDB) 7.9.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin14.3.0".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from m...Reading symbols from /Users/wei/code/gdbtest/m.dSYM/Contents/Resources/DWARF/m...done.
done.
(gdb) break main
Breakpoint 1 at 0x100000eee: file m0.c, line 5.
(gdb) break func
Breakpoint 2 at 0x100000f27: file m1.c, line 5.
(gdb) run
Starting program: /Users/wei/code/gdbtest/m 
warning: Could not open OSO archive file "/BinaryCache/corecrypto/corecrypto-233.1.2~26/Symbols/BuiltProducts/libcorecrypto_static.a"
warning: `/BinaryCache/coreTLS/coreTLS-35.20.2~10/Objects/coretls.build/coretls.build/Objects-normal/x86_64/system_coretls_vers.o': can't open to read symbols: No such file or directory.
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.20.2~10/Symbols/BuiltProducts/libcoretls_ciphersuites.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.20.2~10/Symbols/BuiltProducts/libcoretls_handshake.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.20.2~10/Symbols/BuiltProducts/libcoretls_record.a"
warning: Could not open OSO archive file "/BinaryCache/coreTLS/coreTLS-35.20.2~10/Symbols/BuiltProducts/libcoretls_stream_parser.a"

Breakpoint 1, main () at m0.c:5
5	  gf = 1.23;
(gdb) ptype gf
type = float
(gdb) continue
Continuing.
gf: 1.23

Breakpoint 2, func () at m1.c:5
5	  lf = 4.56;
(gdb) ptype gf
type = float
(gdb) q
A debugging session is active.

	Inferior 1 [process 388] will be killed.

Quit anyway? (y or n) y
wei@r [gdbtest]$ 

Given the size and complexity of your project this may not help you, but compiling in the following way automatically runs dsymutil:

wei@r [gdbtest]$ ls -la
total 16
drwxr-xr-x  4 wei  staff   136B Jul 12 16:29 ./
drwxr-xr-x  8 wei  staff   272B Jul 12 16:13 ../
-rw-r--r--  1 wei  staff   118B Jul 12 16:17 m0.c
-rw-r--r--  1 wei  staff   106B Jul 12 16:13 m1.c
wei@r [gdbtest]$ cc -g m0.c m1.c -o m
wei@r [gdbtest]$ ls -la
total 40
drwxr-xr-x  6 wei  staff   204B Jul 12 16:29 ./
drwxr-xr-x  8 wei  staff   272B Jul 12 16:13 ../
-rwxr-xr-x  1 wei  staff   8.8K Jul 12 16:29 m*
drwxr-xr-x  3 wei  staff   102B Jul 12 16:29 m.dSYM/
-rw-r--r--  1 wei  staff   118B Jul 12 16:17 m0.c
-rw-r--r--  1 wei  staff   106B Jul 12 16:13 m1.c
wei@r [gdbtest]$ 

[Ionic (Mihai Moldovan)]

This (running dsymutil) works for binaries in general.

Closing ticket upon maintainer request.

[rbdavis (Roger Davis)]

Thanks for figuring that out, Stuart, it hadn't occurred to me to try that. I can certainly use it as a workaround when needing to debug something without otherwise changing my build procedure, and that's definitely useful.

Two points, however:

(1) As noted in my original post, the gdb from the current MacPorts gdb-apple port works perfectly well on my example without me having to manually run dsymutil on my executable. Clearly, that version of gdb is somehow able to locate my global symbols in a way which the standard gdb 7.9.1 cannot. I think that is a 7.9.1 deficiency which ought to be fixed.

(2) Every single one of my cc commands includes the -g flag, including each of the .c to .o compiles and the final .o link command. It's rather lame IMHO that after all that I then have to use dsymutil, essentially saying 'No, fellas, I was actually really serious about wanting to be able save all my symbols for debugging purposes just like I said I did the first time.' I have never seen any cc compiling environment require this kind of nonsense, and I've seen a bunch of cc compiling environments. This may be as much a MacOS cc issue (or maybe more generally a clang problem) as a gdb problem, and I will see how far I get with Apple on filing a bug report on their end on this cc behavior.

Thanks again for your workaround, but I hope you will reconsider closure of this bug report given the fact that enough symbol information is being stored somewhere such that gdb-apple can make sense of it where gdb 7.9.1 cannot.

Roger