This will be needed when we add `DW_FORM_strx*` and `DW_FORM_addrx*`
support, which requires us to fetch `DW_AT_str_offsets_base` and
`DW_AT_addr_base` attributes from the parent compilation unit. This
can't be done as we read the values, because it would create infinite
recursion (as we might try to parse the compilation unit's
`DW_FORM_strx*` encoded name before we get to the attribute). Having
getters ensures that we will perform lookups if they are needed.
These API's are used in a variety of ways when building the die cache.
Each AbbreviationEntry has vector and other members, so avoid copying
it at all costs.
This algorithm is both iterative and recursive, so allocating on every
recursion, or when iterating each child is extremely costly.
Instead allow the on stack DIE to be re-initialized so it can be reused.
This helps us avoid weird truncation issues and fixes a bug on Clang
builds where truncation while reading caused the DIE offsets following
large LEB128 numbers to be incorrect. This removes the need for the
separate `LongUnsignedNumber` type.
In the current implementation, only DIE objects that are created via
DIE::for_each_child() will have parent offsets.
DIE objects that are created with CompilationUnit::get_die_at_offset()
do not currently store a parent offset.
We may improve this in the future, but this is enough for what we
currently need.
While symbolicating a crash dump for UserspaceEmulator I came across
another data form we didn't support.
ImplicitConst encodes a LEB128 value in the abbreviation record
rather than - like all other values - in the .debug_info section.
SPDX License Identifiers are a more compact / standardized
way of representing file license information.
See: https://spdx.dev/resources/use/#identifiers
This was done with the `ambr` search and replace tool.
ambr --no-parent-ignore --key-from-file --rep-from-file key.txt rep.txt *
(...and ASSERT_NOT_REACHED => VERIFY_NOT_REACHED)
Since all of these checks are done in release builds as well,
let's rename them to VERIFY to prevent confusion, as everyone is
used to assertions being compiled out in release.
We can introduce a new ASSERT macro that is specifically for debug
checks, but I'm doing this wholesale conversion first since we've
accumulated thousands of these already, and it's not immediately
obvious which ones are suitable for ASSERT.
