cmd/cgo: fails with anonymous struct fields #6472
Labels
Milestone
Comments
FYI, as a workaround until it's fixed proper you can set the environment variable CC=gcc:
20:50 /tmp $ go run sndfile.go
# command-line-arguments
./sndfile.go:16: s.loops undefined (type *_Ctype_SF_INSTRUMENT has no field or method
loops)
20:50 /tmp $ CC=gcc go run sndfile.go
{0}
20:50 /tmp $
|
This is a problem with LLVM. Setting`CC=gcc` doesn't work because gcc on OS X is a gcc front-end backed by LLVM. For now you can avoid LLVM and use plain GNU gcc by installing it with homebrew `brew install gcc48`, then use it by prefixing your build command `CC=gcc-4.9 go build`. For C++ code do `CXX=g++-4.8 go build` instead. When building go you can set the default C compiler like this `CC=gcc-4.8 ./all.bash`. Since revision 1607e9e9e6de you can also set the default C++ compiler: `CC=gcc-4.8 CXX=g++-4.8 ./all.bash`. |
> This is a problem with LLVM.
I disagree, it's a problem with clang, not LLVM. My paste from above was running on my
MBP with the "regular" OS X llvm backed gcc, no need to involve homebrew. Just to be
verbose:
21:39 /tmp $ go run sndfile.go
# command-line-arguments
./sndfile.go:16: s.loops undefined (type *_Ctype_SF_INSTRUMENT has no field or method
loops)
21:39 /tmp $ cc --version
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.3.0
Thread model: posix
21:39 /tmp $ CC=gcc go run sndfile.go
{0}
21:39 /tmp $ gcc --version
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM
build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
21:39 /tmp $ which gcc
/usr/bin/gcc
21:40 /tmp $ ls -l /usr/bin/gcc
lrwxr-xr-x 1 root wheel 12 21 Apr 10:45 /usr/bin/gcc@ -> llvm-gcc-4.2
21:40 /tmp $ ls -l /usr/bin/llv
llvm-cpp-4.2 llvm-g++ llvm-g++-4.2 llvm-gcc llvm-gcc-4.2
21:40 /tmp $ ls -l /usr/bin/llvm-gcc
llvm-gcc llvm-gcc-4.2
21:40 /tmp $ ls -l /usr/bin/llvm-gcc-4.2
lrwxr-xr-x 1 root wheel 32 21 Apr 10:45 /usr/bin/llvm-gcc-4.2@ ->
../llvm-gcc-4.2/bin/llvm-gcc-4.2
21:40 /tmp $ ls -l /usr/llvm-gcc-4.2/bin/ll
llvm-c++-4.2 llvm-cpp-4.2 llvm-g++-4.2 llvm-gcc-4.2
21:40 /tmp $ ls -l /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
-rwxr-xr-x 1 root wheel 117168 21 Apr 10:45 /usr/llvm-gcc-4.2/bin/llvm-gcc-4.2*
|
This is (of course) clang's fault. Here is an interesting dump:
g% cat x.c
typedef struct s1 {
struct s2 {
int mode;
} loops[16];
} s1;
typedef struct s3 {
struct {
int mode;
} loops[16];
} s3;
s1 x;
s3 y;
g% clang -ggdb -c x.c
g% dwarfdump x.o
----------------------------------------------------------------------
File: x.o (x86_64)
----------------------------------------------------------------------
.debug_info contents:
0x00000000: Compile Unit: length = 0x000000e3 version = 0x0002 abbr_offset =
0x00000000 addr_size = 0x08 (next CU at 0x000000e7)
0x0000000b: TAG_compile_unit [1] *
AT_producer( "Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)" )
AT_language( DW_LANG_C99 )
AT_name( "x.c" )
AT_entry_pc( 0x0000000000000000 )
AT_stmt_list( 0x00000000 )
AT_comp_dir( "/Users/rsc" )
0x00000026: TAG_base_type [2]
AT_name( "int" )
AT_encoding( DW_ATE_signed )
AT_byte_size( 0x04 )
0x0000002d: TAG_structure_type [3] *
AT_name( "s2" )
AT_byte_size( 0x04 )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 2 )
0x00000035: TAG_member [4]
AT_name( "mode" )
AT_type( {0x00000026} ( int ) )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 3 )
AT_data_member_location( +0 )
AT_accessibility( DW_ACCESS_public )
0x00000044: NULL
0x00000045: TAG_base_type [5]
AT_byte_size( 0x04 )
AT_encoding( DW_ATE_signed )
0x00000048: TAG_array_type [6] *
AT_type( {0x0000002d} ( s2 ) )
0x0000004d: TAG_subrange_type [7]
AT_type( {0x00000045} ( base ) )
AT_upper_bound( 0x0f )
0x00000053: NULL
0x00000054: TAG_structure_type [3] *
AT_name( "s1" )
AT_byte_size( 0x40 )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 1 )
0x0000005c: TAG_member [4]
AT_name( "loops" )
AT_type( {0x00000048} ( s2[] ) )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 4 )
AT_data_member_location( +0 )
AT_accessibility( DW_ACCESS_public )
0x0000006b: NULL
0x0000006c: TAG_typedef [8]
AT_type( {0x00000054} ( s1 ) )
AT_name( "s1" )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 5 )
0x00000077: TAG_variable [9]
AT_name( "x" )
AT_type( {0x0000006c} ( s1 ) )
AT_external( 0x01 )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 13 )
AT_location( [0x0000000000000000] )
0x0000008d: TAG_array_type [6] *
AT_type( {0x000000a1} ( struct ) )
0x00000092: TAG_subrange_type [7]
AT_type( {0x00000045} ( base ) )
AT_upper_bound( 0x0f )
0x00000098: NULL
0x00000099: TAG_structure_type [3] *
AT_name( "s3" )
AT_byte_size( 0x40 )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 7 )
0x000000a1: TAG_structure_type [10] *
AT_byte_size( 0x04 )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 8 )
0x000000a5: TAG_member [4]
AT_name( "mode" )
AT_type( {0x00000026} ( int ) )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 9 )
AT_data_member_location( +0 )
AT_accessibility( DW_ACCESS_public )
0x000000b4: NULL
0x000000b5: TAG_member [4]
AT_name( "loops" )
AT_type( {0x0000008d} ( struct [] ) )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 10 )
AT_data_member_location( +0 )
AT_accessibility( DW_ACCESS_public )
0x000000c4: NULL
0x000000c5: TAG_typedef [8]
AT_type( {0x00000099} ( s3 ) )
AT_name( "s3" )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 11 )
0x000000d0: TAG_variable [9]
AT_name( "y" )
AT_type( {0x000000c5} ( s3 ) )
AT_external( 0x01 )
AT_decl_file( "/Users/rsc/x.c" )
AT_decl_line( 14 )
AT_location( [0x0000000000000000] )
0x000000e6: NULL
g%
The named version (s1/s2) is fine: s1 is at 0x54...0x6b and s2 is at 0x2d...0x44. The
unnamed version (s3) contains the anonymous inner struct definition at offsets
0xa1...0xb4 nested *inside* the outer struct definition at 0x99...0xc4. Despite this,
the array of 16 of those structs has a type outside the outer struct (0x8d...0x98). We
could argue about whether it's even valid to place the inner struct where it is, but we
can handle it now that we know to expect it.
Sigh.
Labels changed: added go1.2, removed go1.2maybe. |
|
Issue #6368 has been merged into this issue. |
|
This issue was closed by revision 0965459. Status changed to Fixed. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: