5 Commits

Author SHA1 Message Date
Austin Clements
b079640404 misc/cgo/test: simplify for module mode
When we were first introducing module mode, CL 163418 moved many of
the tests in misc/cgo/test into their own test binary under testdata
so misc/cgo/test continued to work in both GOPATH mode and module
mode. This introduce a somewhat complicated test driver into
misc/cgo/test. Since the misc/cgo/test test had to invoke "go test" as
a subprocess, this required care to thread any build flags down into
the subprocess. The output from any failures of the sub-process was
also less than ideal.

Now that we don't have to worry about running these in GOPATH mode any
more, this CL moves all of the tests back into misc/cgo/test and drops
the test driver.

There are two slight complications:

- Test41761 was added after this split and has a C type "S" that's
  also present in misc/cgo/test itself. We rename that to keep that
  test working.

- TestCgo in go/internal/srcimporter now fails to import misc/cgo/test
  because misc/cgo/test now contains imports of other "misc" module
  packages and the importer it sets up isn't configured to allow that.
  We fix this by setting up a build context that's configured for
  this.

Preparation for #37486.

Change-Id: I3c4f73540e0482bbd493823cca44b0ce7fac01f3
Reviewed-on: https://go-review.googlesource.com/c/go/+/447355
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
2022-11-04 20:47:59 +00:00
Bryan C. Mills
551af5f50a misc/cgo/test: fix tests in module mode
This change preserves the ability to test misc/cgo/test in GOPATH
mode, at the cost of indirection through a 'go test' subprocess.

Updates #30228

Change-Id: I08de855e62278d30fa622b2f7478e43dd2ab0e96
Reviewed-on: https://go-review.googlesource.com/c/163418
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2019-02-24 00:35:18 +00:00
Austin Clements
30d7e6449f misc/cgo/test: disable some Darwin tests in cgo mode
For unknown reasons, linking against CoreFoundation on macOS 10.10
sometimes causes mmap to ignore the hint address, which makes the Go
allocator incompatible with TSAN. Currently, the effect of this is to
run the allocator out of arena hints on the very first allocation,
causing a "too many address space collisions for -race mode" panic.

This CL skips the cgo tests that link against CoreFoundation in race
mode.

Updates #26475.
Updates #26513.

Change-Id: I52ec638c99acf5d4966e68ff0054f7679680dac6
Reviewed-on: https://go-review.googlesource.com/125304
Run-TryBot: Austin Clements <austin@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Keith Randall <khr@golang.org>
2018-07-23 15:16:01 +00:00
Keith Randall
b888a6227f cmd/cgo: fix cgo bad typedefs
Two fixes:

1) Typedefs of the bad typedefs should also not be rewritten to the
   underlying type.  They shouldn't just be uintptr, though, they should
   retain the C naming structure.  For example, in C:

   typedef const __CFString * CFStringRef;
   typedef CFStringRef SecKeyAlgorithm;

   we want the Go:

   type _Ctype_CFStringRef uintptr
   type _Ctype_SecKeyAlgorithm = _Ctype_CFStringRef

2) We need more types than just function arguments/return values.
   At least we need types of global variables, so when we see a reference to:

   extern const SecKeyAlgorithm kSecKeyAlgorithmECDSASignatureDigestX962SHA1;

   we know that we need to investigate the type SecKeyAlgorithm.
   Might as well just find every typedef and check the badness of all of them.
   This requires looping until a fixed point of known types is reached.
   Usually it takes just 2 iterations, sometimes 3.

Fixes #24161

Change-Id: I32ca7e48eb4d4133c6242e91d1879636f5224ea9
Reviewed-on: https://go-review.googlesource.com/123177
Run-TryBot: Keith Randall <khr@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-07-12 19:15:12 +00:00
Keith Randall
94076feef5 cmd/cgo: check function argument/return types for bad C pointer types
We need to determine whether arguments to and return values from C
functions are "bad" typedef'd pointer types which need to be uintptr
on the Go side.

The type of those arguments are not specified explicitly. As a result,
we never look through the C declarations for the GetTypeID functions
associated with that type, and never realize that they are bad.
However, in another function in the same package there might be an
explicit reference. Then we end up with the declaration being uintptr
in one file and *struct{...} in another file. Badness ensues.

Fix this by doing a 2-pass algorithm. In the first pass, we run as
normal, but record all the argument and result types we see. In the
second pass, we include those argument types also when reading the C
types.

Fixes #24161

Change-Id: I8d727e73a2fbc88cb9d9899f8719ae405f59f753
Reviewed-on: https://go-review.googlesource.com/122575
Run-TryBot: Keith Randall <khr@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-07-09 22:19:21 +00:00