os.Kill cannot be caught on Unix systems.
The example gives the false impression that it can.
Fixes#13080.
Change-Id: I3b9e6f38a38f437a463c5b869ae84a0d3fd23f72
Reviewed-on: https://go-review.googlesource.com/16467
Reviewed-by: Andrew Gerrand <adg@golang.org>
This is needed to make external linking work.
Change-Id: I4cf7edb4ea318849cab92a697952f8745eed40c4
Reviewed-on: https://go-review.googlesource.com/14237
Reviewed-by: Ian Lance Taylor <iant@golang.org>
In the same manner in which runtime/cgo is included on other architectures.
Change-Id: I90a5ad8585248b2566d763d33994a600508d89cb
Reviewed-on: https://go-review.googlesource.com/14221
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Android linker does not handle TLS for us. We set up the TLS slot
for g, as darwin/386,amd64 handle instead. This is disgusting and
fragile. We will eventually fix this ugly hack by taking advantage
of the recent TLS IE model implementation. (Instead of referencing
an GOT entry, make the code sequence look into the TLS variable that
holds the offset.)
The TLS slot for g in android/amd64 assumes a fixed offset from %fs.
See runtime/cgo/gcc_android_amd64.c for details.
For golang/go#10743
Change-Id: I1a3fc207946c665515f79026a56ea19134ede2dd
Reviewed-on: https://go-review.googlesource.com/15991
Reviewed-by: David Crawshaw <crawshaw@golang.org>
In the Go signal handler on Plan 9, when a signal with
the _SigThrow flag is received, we call startpanic before
printing the stack trace.
The startpanic function calls systemstack which calls
startpanic_m. In the startpanic_m function, we call
allocmcache to allocate _g_.m.mcache. The problem is
that allocmcache calls nextSample, which does a floating
point operation to return a sampling point for heap profiling.
However, Plan 9 doesn't support floating point in the
signal handler.
This change adds a new function nextSampleNoFP, only
called when in the Plan 9 signal handler, which is
similar to nextSample, but avoids floating point.
Change-Id: Iaa30437aa0f7c8c84d40afbab7567ad3bd5ea2de
Reviewed-on: https://go-review.googlesource.com/16307
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
The dynamic linker on linux/386 stores the address of the vsyscall helper at a
fixed offset from the %gs register on linux/386 for easy access from PIC code.
Change-Id: I635305cfecceef2289985d62e676e16810ed6b94
Reviewed-on: https://go-review.googlesource.com/16346
Reviewed-by: Ian Lance Taylor <iant@golang.org>
This part got dropped when we were debating between two solutions
in https://golang.org/cl/15151Fixes#13032
Change-Id: I820b94f6c0c102ccf9342abf957328ea01f49a26
Reviewed-on: https://go-review.googlesource.com/16313
Reviewed-by: Austin Clements <austin@google.com>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
arena_{start,used,end} are already uintptr, so no need to convert them
to uintptr, much less to convert them to unsafe.Pointer and then to
uintptr. No binary change to pkg/linux_amd64/runtime.a.
Change-Id: Ia4232ed2a724c44fde7eba403c5fe8e6dccaa879
Reviewed-on: https://go-review.googlesource.com/16339
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
There is no signal list on Plan 9, since notes
are strings. However, some programs expect
signals to be defined in the syscall package.
Hence, we define a list of the most common notes.
Updates #11975.
Change-Id: I852e14fd98777c9595a406e04125be1cbebed0fb
Reviewed-on: https://go-review.googlesource.com/16301
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Implement an abort note on Plan 9, as an
equivalent of the SIGABRT signal on other
operating systems.
Updates #11975.
Change-Id: I010c9b10f2fbd2471aacd1d073368d975a2f0592
Reviewed-on: https://go-review.googlesource.com/16300
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Run-TryBot: David du Colombier <0intro@gmail.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
When a new tiny block is allocated because we're allocating an object
that won't fit into the current block, mallocgc saves the new block if
it has more space leftover than the old block. However, the logic for
this was subtly broken in golang.org/cl/2814, resulting in never
saving (or consequently reusing) a tiny block.
Change-Id: Ib5f6769451fb82877ddeefe75dfe79ed4a04fd40
Reviewed-on: https://go-review.googlesource.com/16330
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Necessary to ensure that subsequent tools can continue to find
then end of the export data section simply by searching for "$$".
Adjusted gcimporter used by go/types accordingly.
Also, fixed a bug in gcimporter related to reading export data
in debug format.
Change-Id: Iaea4ed05edd8a5bab28ebe5b19a4740f5e537d35
Reviewed-on: https://go-review.googlesource.com/16283
Reviewed-by: Chris Manghane <cmang@golang.org>
It's the only ARM version we have ever supported on android.
(Not setting it caused some builder timeouts.)
Change-Id: I26061434252ff2a236bb31d95787a1c582d24b3f
Reviewed-on: https://go-review.googlesource.com/16295
Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
I went looking for an arm system whose stacks are by default smaller
than 64KB. In fact the smallest common linux target I could find was
Android, which like iOS uses 1MB stacks.
Fixes#11873
Change-Id: Ieeb66ad095b3da18d47ba21360ea75152a4107c6
Reviewed-on: https://go-review.googlesource.com/14602
Reviewed-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Reviewed-by: Minux Ma <minux@golang.org>
gc will need to be rebuild.
Package that assume f.PkgPath != nil means a field is unexported and
must be ignored must be revised to check for
f.PkgPath != nil && !f.Anonymous,
so that they do try to walk into the embedded fields to look for
exported fields contained within.
Closes#12367, fixes#7363, fixes#11007, and fixes#7247.
Change-Id: I16402ee21ccfede80f277f84b3995cf26e97433d
Reviewed-on: https://go-review.googlesource.com/14085
Reviewed-by: Russ Cox <rsc@golang.org>
Addresses issue #12367.
Must be checked in before CL 14010.
Change-Id: I4523a1de112ed02371504e27882659bce8028a9f
Reviewed-on: https://go-review.googlesource.com/14012
Reviewed-by: Russ Cox <rsc@golang.org>
Addresses issue #12367.
Must be checked in before CL 14010.
Change-Id: I7233c3a62d4f55d0ac7e8a87df5fc4ee7beb7207
Reviewed-on: https://go-review.googlesource.com/14011
Reviewed-by: Russ Cox <rsc@golang.org>
Cover some functions that weren't benched before and add InString
variants if the underlying implementation is different.
Note: compare (Valid|RuneCount)InString* to their (Valid|RuneCount)*
counterparts. It shows, somewhat unexpectedly, that ranging over
a string is *much* slower than using calls to DecodeRune.
Results:
In order to avoid a discrepancy in measuring the performance
of core we could leave the names of the string-based measurements
unchanged and suffix the added alternatives with Bytes.
Compared to old:
BenchmarkRuneCountTenASCIIChars-8 44.3 12.4 -72.01%
BenchmarkRuneCountTenJapaneseChars-8 167 67.1 -59.82%
BenchmarkEncodeASCIIRune-8 3.37 3.44 +2.08%
BenchmarkEncodeJapaneseRune-8 7.19 7.24 +0.70%
BenchmarkDecodeASCIIRune-8 5.41 5.53 +2.22%
BenchmarkDecodeJapaneseRune-8 8.17 8.41 +2.94%
All benchmarks:
BenchmarkRuneCountTenASCIIChars-8 100000000 12.4 ns/op
BenchmarkRuneCountTenJapaneseChars-8 20000000 67.1 ns/op
BenchmarkRuneCountInStringTenASCIIChars-8 30000000 44.5 ns/op
BenchmarkRuneCountInStringTenJapaneseChars-8 10000000 165 ns/op
BenchmarkValidTenASCIIChars-8 100000000 12.5 ns/op
BenchmarkValidTenJapaneseChars-8 20000000 71.1 ns/op
BenchmarkValidStringTenASCIIChars-8 30000000 50.0 ns/op
BenchmarkValidStringTenJapaneseChars-8 10000000 161 ns/op
BenchmarkEncodeASCIIRune-8 500000000 3.44 ns/op
BenchmarkEncodeJapaneseRune-8 200000000 7.24 ns/op
BenchmarkDecodeASCIIRune-8 300000000 5.53 ns/op
BenchmarkDecodeJapaneseRune-8 200000000 8.41 ns/op
BenchmarkFullASCIIRune-8 500000000 3.91 ns/op
BenchmarkFullJapaneseRune-8 300000000 4.22 ns/op
Change-Id: I674d2ee4917b975a37717bbfa1082cc84dcd275e
Reviewed-on: https://go-review.googlesource.com/14431
Reviewed-by: Russ Cox <rsc@golang.org>
This CL changes reflect to allow access to exported fields and
methods in unexported embedded structs for gccgo and after gc
has been adjusted to disallow access to embedded unexported structs.
Adresses #12367, #7363, #11007, and #7247.
Change-Id: If80536eab35abcd25300d8ddc2d27d5c42d7e78e
Reviewed-on: https://go-review.googlesource.com/14010
Reviewed-by: Russ Cox <rsc@golang.org>
This copies the change from CL 16158 (applied as
22d4c8bf13).
Updates #13013
Change-Id: Id7d02e63d92806f06a4e064a91b2fb6574fe385f
Reviewed-on: https://go-review.googlesource.com/16291
Reviewed-by: Minux Ma <minux@golang.org>
Run-TryBot: Minux Ma <minux@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Depends on external linking right now. I have no immediate use for
this, but wanted to check how hard it is to support as android/amd64
is coming and it will require PIE.
Change-Id: I65c6b19159f40db4c79cf312cd0368c2b2527bfd
Reviewed-on: https://go-review.googlesource.com/16072
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: David Crawshaw <crawshaw@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Update old c-style comments to look like Go comments. Also replace some
lingering references to old .c files that don't exist anymore.
Change-Id: I72b2407a40fc76c23e9048643e0622fd70b4cf90
Reviewed-on: https://go-review.googlesource.com/16190
Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org>
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
Regular expressions involving a (x){0} term are
simplified by removing this term from the
expression, just before the expression is compiled.
The number of subexpressions is evaluated before
the simplification. The number of capture instructions
in the compiled expressions is not necessarily in line
with the number of subexpressions.
When the ReplaceAll(String) methods are used, a number
of capture slots (nmatch) is evaluated as 2*(s+1)
(s being the number of subexpressions).
In some case, it can be higher than the number of capture
instructions evaluated at compile time, resulting in a
panic when the internal slices of regexp.machine
are resized to this value.
Fixed by capping the number of capture slots to the number
of capture instructions.
I must say I do not really see the benefits of setting
nmatch lower than re.prog.NumCap using this 2*(s+1) formula,
so perhaps this can be further simplified.
Fixes#11178Fixes#11176
Change-Id: I21415e8ef2dd5f2721218e9a679f7f6bfb76ae9b
Reviewed-on: https://go-review.googlesource.com/14013
Reviewed-by: Russ Cox <rsc@golang.org>
