| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
