Re-run all go:generate stringer commands. This mostly adds checks
that the constant values did not change, but does add new strings
for the debug/dwarf and internal/pkgbits packages.
Change-Id: I5fc41f20da47338152c183d45d5ae65074e2fccf
Reviewed-on: https://go-review.googlesource.com/c/go/+/483717
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Ian Lance Taylor <iant@google.com>
Reviewed-by: Ian Lance Taylor <iant@google.com>
Auto-Submit: Ian Lance Taylor <iant@google.com>
TryBot-Result: Gopher Robot <gobot@golang.org>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
Also add a few other missing constants.
Also rerun current version of stringer.
Change-Id: I004ef27f6b40fe2cab64c52d169255dfea43fa01
Reviewed-on: https://go-review.googlesource.com/c/go/+/175137
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
By grepping for ]string{$, one can find many manual implementations of
stringer. The debug/dwarf ones needed the new -trimprefix flag, too.
html/template was fairly simple, just implementing the fallback as
stringer would. The changes there are trivial.
The ones in debug/dwarf needed a bit of extra logic since the GoString
wants to use its own format, depending on whether or not the value is
one of the known constants.
Change-Id: I501ea7deaa538fa425c8e9c2bb895f480169273f
Reviewed-on: https://go-review.googlesource.com/77253
Run-TryBot: Daniel Martí <mvdan@mvdan.cc>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Currently, if the .debug_abbrev section of an ELF file contains
attributes that aren't known to the dwarf package and that have form
formSecOffset, the dwarf package will fail to open the DWARF data with
an error like "decoding dwarf section abbrev at offset 0x17: cannot
determine class of unknown attribute with formSecOffset". For the most
part, the class is implied by the form encoded in the abbrev section,
but formSecOffset can imply many different DWARF classes. Hence,
debug/dwarf disambiguates these using a table of known attributes.
However, it will reject the entire image if it encounters an attribute
it can't determine the class of. This is particularly unfortunate
because the caller may never even uses the offending attribute.
Fix this by introducing a ClassUnknown attribute class to use as a
fallback in these cases. This allows the dwarf package to load the
DWARF data and isolates the problem to just the affected attributes.
Fixes#12592.
Change-Id: I766227b136e9757f8b89c0b3ab8e9ddea899d94f
Reviewed-on: https://go-review.googlesource.com/14541
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: jcd . <jcd@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>
Ian Lance Taylor
Daniel Martí
Austin Clements
John Dethridge