Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cmd/cgo: mysterious missing typedef[...] definition on Mac OS X handling internal Objective-C types #8238

Closed
andlabs opened this issue Jun 19, 2014 · 8 comments

Comments

@andlabs
Copy link
Contributor

commented Jun 19, 2014

from src/cmd/cgo/gcc.go:
  1286              if isStructUnionClass(sub.Go) {
  1287                  // Use the typedef name for C code.
  1288                  typedef[sub.Go.(*ast.Ident).Name].C = t.C
  1289              }

When handling one of Objective-C's internal types, go get github.com/andlabs/ui fails
with a nil pointer dereference panic at line 1288 above. Upon further investigation:

### sub.Go:&ast.Ident{NamePos:0, Name:"_Ctype_struct_objc_object",
Obj:(*ast.Object)(nil)} sub.Go.(*ast.Ident):&ast.Ident{NamePos:0,
Name:"_Ctype_struct_objc_object", Obj:(*ast.Object)(nil)}
....Name:"_Ctype_struct_objc_object"
typedef:map[string]*main.Type{"_Ctype_struct_objc_cache":(*main.Type)(0x2083eacc0),
"_Ctype_int":(*main.Type)(0x2084d7480),
"_Ctype_struct_objc_method_list":(*main.Type)(0x2084d7e00),
"_Ctype_SEL":(*main.Type)(0x2084d7b00),
"_Ctype_Class":(*main.Type)(0x2084d7040),
"_Ctype_long":(*main.Type)(0x2084d7280),
"_Ctype_struct_objc_ivar":(*main.Type)(0x2084d7700),
"_Ctype_Method":(*main.Type)(0x2083eac00),
"_Ctype_struct_objc_selector":(*main.Type)(0x2084d7a80),
"_Ctype_IMP":(*main.Type)(0x2084d7cc0),
"_Ctype_struct_objc_method":(*main.Type)(0x2084d7d80),
"_Ctype_uint":(*main.Type)(0x2084d7f80),
"_Ctype_Protocol":(*main.Type)(0x2083eb000),
"_Ctype_char":(*main.Type)(0x2084d71c0),
"_Ctype_struct_objc_ivar_list":(*main.Type)(0x2084d7780)}
t:&main.Type{Size:8, Align:-1, C:(*main.TypeRepr)(0x2084f66f0),
Go:(*ast.Ident)(0x2084e53c0), EnumValues:map[string]int64(nil), Typedef:""}
t.C:&main.TypeRepr{Repr:"Protocol", FormatArgs:[]interface {}(nil)}
### expr:(*main.Type)(nil)

so while all the parts of the typedef[...] line are valid, the typedef[...] expression
itself is not. I'm not sure what's going on here.

I'm running Mac OS X 10.8 with go version
    go version devel +f39dff1bf0d4 Thu Jun 19 22:18:24 2014 +1000 darwin/amd64
and clang version
    Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
    Target: x86_64-apple-darwin12.5.0
    Thread model: posix
but people at andlabs/ui#9 have different setups.

Thanks!
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2014

Comment 1:

I think we must be setting the typedef without seeing the struct to which it is
typedef'ed.
Try changing that line to do nothing if there is no entry in the typedef map and see
what happens.

Labels changed: added repo-main, release-go1.3.1.

@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Jun 19, 2014

Comment 2:

I haven't been able to reproduce this on GNU/Linux.  Can you try to reduce this to a
small standalone test case?  It would be even better if the test case could be in C.
@andlabs

This comment has been minimized.

Copy link
Contributor Author

commented Jun 19, 2014

Comment 3:

jrick (the conformal/gotk3 guy) seems to think this is a clang-specific problem. (I
wouldn't be surprised...)
[11:30] <jrick> andlabs: I think issue #8238 is related to clang, when I build go
1.3 with gcc, cgo doesn't panic (but I get other weirdness with *C.T and *C.struct__T
errors)
[11:32] <jrick> what's even more odd is that the *C.struct__T errors don't seem
deterministic
[11:32] <jrick> i.e. run go get once, and the build fails
[11:33] <jrick> run it again, and everything works :/
[11:33] <jrick> I wonder if my glib/gtk packages are built with clang
That being said, I can try both comments's requests on OS X later (and then remember how
to use GNUstep for a Linux-based example).
@andlabs

This comment has been minimized.

Copy link
Contributor Author

commented Jun 19, 2014

Comment 4:

"Try changing that line to do nothing if there is no entry in the typedef map and see
what happens."
No panic; everything seems to compile and run fine.
Minimal test:
    package main
    // #cgo LDFLAGS: -framework Foundation -lobjc
    // #include <objc/message.h>
    // #include <objc/objc.h>
    // #include <objc/runtime.h>
    import "C"
    func main() { var x C.id; println(x) }
Can't reproduce on Linux; compilation works fine but fails during link due to
incompatible linker options in the LDFLAGS above.
    pietro@pietro-laptop:/tmp$ gcc --version
    gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2
    Copyright (C) 2013 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.
    
    pietro@pietro-laptop:/tmp$ clang --version
    Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
    Target: x86_64-pc-linux-gnu
    Thread model: posix
@mdempsky

This comment has been minimized.

Copy link
Member

commented Aug 6, 2014

Comment 5:

FYI, we just committed revision 0015a25415455c390ae135bef7de2d5e2b10ee88 to fix issue
8368, which was another nil pointer dereference at gcc.go:1288.  It would be interesting
to know if you're still able to reproduce this issue at tip.
@gopherbot

This comment has been minimized.

Copy link

commented Aug 6, 2014

Comment 6 by joshrickmar:

I've been able to build gotk3 using a clang-built go tip several times now with no
panics or other issues (that also includes the missing typedef issues from issue #8463).
@ianlancetaylor

This comment has been minimized.

Copy link
Contributor

commented Aug 6, 2014

Comment 7:

Sounds like this was fixed--please reopen if not.

Status changed to Duplicate.

Merged into issue #8368.

@rsc

This comment has been minimized.

Copy link
Contributor

commented Aug 11, 2014

Comment 8:

Labels changed: added release-none, removed release-go1.3.1.

@golang golang locked and limited conversation to collaborators Jun 25, 2016

This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
5 participants
You can’t perform that action at this time.