dwarf: fixup x86 register mapping logic
dwarf: change the register context update to update in-place instead of copying
debug: always print the unwind error type
This change enhances stack trace output to include a note that debug info was missing,
and therefore the stack trace may not be accurate. For example, if the user is using a libc
compiled with -fomit-frame-pointer and doesn't have debug symbols installed, any traces
that begin in a libc function may not unwind correctly. This allows the user to notice this and
potentially install debug symbols to improve the output.
Some DWARF5 subprograms have non-contiguous instruction ranges. An example of such
a function is `puts` in Ubuntu's libc. This change fixes name lookups for functions that use
DW_AT_range in their DIE.
- Fix unwindFrame using the previous FDE row instead of the current one
- Handle unwinding through noreturn functions
- Add x86-linux getcontext
- Fixup x86_64-linux getcontext not restoring the fp env
- Fix start_addr filtering on x86-windows
- .eh_frame_hdr contains a binary-searchable data structure for finding an FDE. If present, we can use this
section to avoid having to parse the entire FDE/CIE list in the binary, instead only entries that are actually
required for unwinding are read.
- rework the inputs pc-relative pointer decoding to support both already-mapped sections as well as sections
mapped from a file
- store the VirtualMachine on UnwindContext so the allocations can be reused
Most of this migration was performed automatically with `zig fmt`. There
were a few exceptions which I had to manually fix:
* `@alignCast` and `@addrSpaceCast` cannot be automatically rewritten
* `@truncate`'s fixup is incorrect for vectors
* Test cases are not formatted, and their error locations change
This data changed quite significantly between DWARF 4 and 5. Some
systems are shipping DWARF 5 libraries (Void Linux on musl libc seems to
use it for crt1 etc), which meant when printing stack traces, a random
compile unit might be incorrectly identified as containing an address,
resulting in incorrect location information.
I was consistently experiencing this issue with compiler stack traces,
and this change fixed it.
* CompileStep: Avoid calling producesPdbFile() to determine whether the
option should be respected. If the user asks for it, put it on the
command line and let the Zig CLI deal with it appropriately.
* Make the namespace of `std.dwarf.Format.dwarf32` no longer have a
redundant "dwarf" in it.
* Add `zig cc` integration for `-gdwarf32` and `-gdwarf64`.
* Toss in a bonus bug fix for `-gdwarf-2`, `-gdwarf-3`, etc.
* Avoid using default init values for struct fields unnecessarily.
* Add missing cache hash addition for the new option.
