| Age | Commit message (Collapse) | Author |
|
Simplify slice/map literal expressions.
Caught with gofmt -d -s, fixed with gofmt -w -s
Reformatted some expressions to improve readability.
Change-Id: Iaf123e6bd49162ec45c59297ad3b002ca59443bc
Reviewed-on: https://go-review.googlesource.com/13850
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
|
|
Change-Id: I58453f7ed71eaca15dd3f501e4ae88d1fab19908
Reviewed-on: https://go-review.googlesource.com/12683
Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
Reviewed-by: Rob Pike <r@golang.org>
|
|
The original version of applyRelocationsARM was added in
http://golang.org/cl/7266. It was added to fix the ARM build, which
had been broken by http://golang.org/cl/6780.
Before CL 6780, there was no relocation processing for ARM. CL 6780
changed the code to require relocation processing for every supported
target. CL 7266 fixed the ARM build by adding a relocation processing
function, but in fact no actual processing was done. The code only
looked for REL32 relocations, but ARM debug info has no such
relocations. The test case added in CL 7266 doesn't have any either.
This didn't matter because no relocation processing was required on
ARM, at least not for GCC-generated debug info. GCC generates ABS32
relocations, but only against section symbols which have the value 0.
Therefore, the addition done by correct handling of ABS32 doesn't
change anything.
Clang, however, generates ABS32 relocations against local symbols,
some of which have non-zero values. For those, we need to handle
ABS32 relocations.
This patch corrects the CL 7266 to look for ABS32 relocations instead
of REL32 relocations. The code was already written to correctly
handle ABS32 relocations, it just mistakenly said REL32.
This is the ARM equivalent of https://golang.org/cl/96680045, which
fixed the same problem in the same way for clang on 386.
With this patch, clang-3.5 can be used to build Go on ARM GNU/Linux.
Fixes #8980.
Change-Id: I0c2d72eadfe6373bde99cd03eee40de6a582dda1
Reviewed-on: https://go-review.googlesource.com/11222
Reviewed-by: Russ Cox <rsc@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
|
|
To return DWARF attribute values, debug/dwarf maps the DWARF attribute
value classes to Go types. Unfortunately, this mapping is ambiguous in
a way that makes it impossible to correctly interpret some DWARF
attributes as of DWARF 4. For example, AttrStartScope can be either a
constant or a rangelistptr. The attribute is interpreted differently
depending on its class, but debug/dwarf maps both classes to int64, so
the caller can't distinguish them from the Go type.
AttrDataMemberLocation is similar.
To address this, this change adds a field to type Field that indicates
the exact DWARF attribute value class of that field's value. This
makes it possible to distinguish value classes that can't be
distinguished by their Go type alone.
The root of this type ambiguity was DWARF itself. For example, DWARF 2
made no distinction between constants that were just constants and
constants that were section offsets because no attribute could have
both meanings. Hence, the single int64 type was sufficient. To avoid
introducing just another layer of ambiguity, this change takes pains
to canonicalize ambiguous classes in DWARF 2 and 3 files into the
unambiguous classes of DWARF 4.
Of course, there's no guarantee that future DWARF versions won't do
the same thing again and further subdivide the DWARF 4 classes. This
change gets ahead of this somewhat by distinguishing the various *ptr
classes even though the encoding does not. If there's some other form
of split, we can handle this in a backwards-compatible way by
introducing, for example, a Class5 field and type.
Change-Id: I4ef96d1223b0fd7f96ecf44fcc0e704a36af02b4
Reviewed-on: https://go-review.googlesource.com/8502
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #10118.
Change-Id: I4a2e6748db609c6eed1d68c824b81c59bd7b875c
Reviewed-on: https://go-review.googlesource.com/7590
Reviewed-by: Minux Ma <minux@golang.org>
|
|
This change adds the minimum necessary to implement applyRelocations.
For adg, this code uses the switch statement.
Change-Id: I0989daab8d0e36c2a4f6a315ced258b832744616
Reviewed-on: https://go-review.googlesource.com/7266
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Change-Id: Ia6f9bd77a3d4250339dcb054edc76942864dd358
Reviewed-on: https://go-review.googlesource.com/6781
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Previously, different DWARF sections had relocations applied in very
different ways. .debug_info was relocated, but only on x86-64 and 386
and using hard-coded relocation section names instead of relocation
links. .debug_abbrev and .debug_str were never relocated (which is
excusable because they shouldn't need it). .debug_types sections were
relocated on all architectures and found their relocation section
using a relocation link because section names could be ambiguous.
Simplify all of this so that every DWARF section that has a linked
relocation section gets those relocations applied.
This prepares this code to load .debug_line sections without the need
for yet more ad hoc relocation logic.
Change-Id: Ia00ac8e656b22f22bb31a5f6ef9b0f23cda64d19
Reviewed-on: https://go-review.googlesource.com/6780
Reviewed-by: Rob Pike <r@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
|
Fixes #8654.
LGTM=austin
R=austin
CC=golang-codereviews
https://golang.org/cl/180600043
|
|
This brings dev.power64 up-to-date with the current tip of
default. go_bootstrap is still panicking with a bad defer
when initializing the runtime (even on amd64).
LGTM=rsc
R=rsc
CC=golang-codereviews
https://golang.org/cl/152570049
|
|
This also removes pkg/runtime/traceback_lr.c, which was ported
to Go in an earlier commit and then moved to
runtime/traceback.go.
Reviewer: rsc@golang.org
rsc: LGTM
|
|
LGTM=bradfitz
R=golang-codereviews, bradfitz
CC=golang-codereviews
https://golang.org/cl/155190043
|
|
Preparation was in CL 134570043.
This CL contains only the effect of 'hg mv src/pkg/* src'.
For more about the move, see golang.org/s/go14nopkg.
|