* Let's consolidate the special-cased DWARF interpreter for OSX with the
general purpose one
* Drop the assumption that all the debug data is contained in a single
contiguous slice of memory. This is a good news for freestanding
targets and paves the way for supporting compressed debug sections.
Let's always subtract 1 from the return address so that we're sure to be
inside the callee.
Fixes some edge case where the stack trace skipped the first entry.
in stack tracing code, the idea was to detect the tty settings at the
top of the stack and pass the information down. somewhere along the way
this got changed so that setTtyColor was assuming the global stderr_file
was related to the output stream the stack trace was being printed to.
now, tty_color is changed to tty_config, and it is an enum rather than a
bool, telling how tty colors are expected to be handled. windows is
still incorrectly looking at stderr_file.
These were never working with native CPU features. In this branch,
we fix native CPU features not being enabled on Windows, and regress
f128 language features. In the llvm10 branch, all this is fixed,
and the tests are re-enabled.
Previously it was a tagged union which was one of:
* baseline
* a specific CPU
* a set of features
Now, it's possible to have a CPU but also modify the CPU's feature set
on top of that. This is closer to what LLVM does.
This is more correct because Zig's notion of CPUs (and LLVM's) is not
exact CPU models. For example "skylake" is not one very specific model;
there are several different pieces of hardware that match "skylake" that
have different feature sets enabled.
comment from this commit reproduced here:
I have observed the CPU name reported by LLVM being incorrect. On
the SourceHut build services, LLVM 9.0 reports the CPU as "athlon-xp",
which is a 32-bit CPU, even though the system is 64-bit and the reported
CPU features include, among other things, +64bit.
So the strategy taken here is that we observe both reported CPU, and the
reported CPU features. The features are trusted more; but if the features
match exactly the features of the reported CPU, then we trust the reported CPU.