[MacPorts] #48284: gdb @7.9.1_0: cannot determine type of primitive global variables (was: gdb 7.9.1 cannot determine type of primitive global variables)

MacPorts noreply at macports.org
Tue Jul 7 20:06:37 PDT 2015


#48284: gdb @7.9.1_0: cannot determine type of primitive global variables
---------------------+-------------------------------
  Reporter:  rbd@…   |      Owner:  stuartwesterman@…
      Type:  defect  |     Status:  new
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:  2.3.3
Resolution:          |   Keywords:
      Port:  gdb     |
---------------------+-------------------------------
Changes (by larryv@…):

 * cc: stuartwesterman@…, openmaintainer@… (removed)
 * owner:  macports-tickets@… => stuartwesterman@…
 * keywords:  global variable types unknown =>


Old description:

> 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[[BR]]
> #include <stdio.h>[[BR]]
> float gf;[[BR]]
> extern void func();[[BR]]
> int main() {
>         gf= 1.23;[[BR]]
>         printf("gf: %4.2f\n", gf);[[BR]]
>         func();[[BR]]
> }[[BR]]
>
> % cat m1.c[[BR]]
> #include <stdio.h>[[BR]]
> extern float gf;[[BR]]
> void func() {
>         float lf;[[BR]]
>         lf= 4.56;[[BR]]
>         printf("lf: %4.2f\n", lf);[[BR]]
> }[[BR]]
>
> Then compile as follows:
>
> % cc -g -c m0.c -o m0.o[[BR]]
> % cc -g -c m1.c -o m1.o[[BR]]
> % 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[[BR]]
> GNU gdb (GDB) 7.9.1[[BR]]
> ...[[BR]]
> This GDB was configured as "x86_64-apple-darwin14.3.0".[[BR]]
> ...[[BR]]
> Reading symbols from m...done.[[BR]]
> (gdb) break main[[BR]]
> Breakpoint 1 at 0x100000eee: file m0.c, line 5.[[BR]]
> (gdb) break func[[BR]]
> Breakpoint 2 at 0x100000f27: file m1.c, line 5.[[BR]]
> (gdb) run[[BR]]
> Starting program: /private/tmp/m[[BR]]
> 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.[[BR]]
> warning: Could not open OSO archive file
> "/BinaryCache/coreTLS/coreTLS-35.30.2~2/Symbols/BuiltProducts/libcoretls_ciphersuites.a"[[BR]]
> warning: Could not open OSO archive file
> "/BinaryCache/coreTLS/coreTLS-35.30.2~2/Symbols/BuiltProducts/libcoretls_handshake.a"[[BR]]
> warning: Could not open OSO archive file
> "/BinaryCache/coreTLS/coreTLS-35.30.2~2/Symbols/BuiltProducts/libcoretls_record.a"[[BR]]
> warning: Could not open OSO archive file
> "/BinaryCache/coreTLS/coreTLS-35.30.2~2/Symbols/BuiltProducts/libcoretls_stream_parser.a"[[BR]]
> Breakpoint 1, main () at m0.c:5[[BR]]
> 5               gf= 1.23;[[BR]]
> (gdb) s[[BR]]
> 6               printf("gf: %4.2f\n", gf);[[BR]]
> (gdb) s[[BR]]
> gf: 1.23[[BR]]
> 7               func();[[BR]]
> (gdb) ptype gf[[BR]]
> type = <data variable, no debug info>[[BR]]
> (gdb) print gf[[BR]]
> $1 = 1067282596
>
> However, the type of local float lf within func is known:
>
> (gdb) continue[[BR]]
> Continuing.[[BR]]
> Breakpoint 2, func () at m1.c:5[[BR]]
> 5               lf= 4.56;[[BR]]
> (gdb) s[[BR]]
> 6               printf("lf: %4.2f\n", lf);[[BR]]
> (gdb) s[[BR]]
> lf: 4.56[[BR]]
> 7       }[[BR]]
> (gdb) ptype lf[[BR]]
> type = float[[BR]]
> (gdb) print lf[[BR]]
> $2 = 4.55999994
>
> The type of the global float gf is also unknown to gdb from within
> func():
>
> (gdb) ptype gf[[BR]]
> type = <data variable, no debug info>[[BR]]
> (gdb) print gf[[BR]]
> $3 = 1067282596
>
> If instead you combine the two files m[01].c into the single file s.c
> with the contents
>
> #include <stdio.h>[[BR]]
> float gf;[[BR]]
> int main() {
>         void func();[[BR]]
>         gf= 1.23;[[BR]]
>         printf("gf: %4.2f\n", gf);[[BR]]
>         func();
> }
>
> void func() {
>         float lf;[[BR]]
>         lf= 4.56;[[BR]]
>         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

New description:

 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

--

Comment:

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

-- 
Ticket URL: <https://trac.macports.org/ticket/48284#comment:1>
MacPorts <https://www.macports.org/>
Ports system for OS X


More information about the macports-tickets mailing list