* Advance line and PC prior to ending sequence in debug line program
for a fn_decl. This is equivalent to closing scope in the debugger
and without it, the debugger will not map source-to-address info
as a result will not print the source when breaking at a symbol.
* Fix debug aranges sentinels to be of the size as the actual tuple
descriptor (assuming segment selector to be ommitted). In summary,
the sentinels were 32bit 0s, whereas they ought to be 64bit 0s.
* Make naming of symbols in the binary more consistent by prefixing
each symbol name with an underscore '_'.
Originally, I thought that the dSYM bundle has to reside side-by-side
with the binary it carries the debugging information for. However, it
turns out macOS is clever enough that it auto-searches for matching
dSYM bundle based on the embedded UUID of the binary.
To verify this, run this on your macOS:
```
mdfind "com_apple_xcode_dsym_uuids == <UUID from LC_UUID>"
```
See [here] for more info.
[here]: https://developer.apple.com/documentation/xcode/adding-identifiable-symbol-names-to-a-crash-report
* `-lc++` now implies `-lc`.
* `-lunwind` is now pulled out into a separate `link_libunwind` flag in
the frontend driver code. This allows a project to request zig to
provide libunwind even if the default situation that causes it to be
implicitly added, is not active.
* build.zig: ask for -lunwind when building the self-hosted compiler on
Linux. Otherwise we get linker errors with unresolved symbols to
libunwind.
* for cross testing stage2 tests, we use `darling shell` command
since the path to the tested binary is relative to cwd
* for the `zig test` command, we simply use `darling` since the
path to the binary is absolute
5ac91794cce8bd53916a378815be01e4365d53d9 made Zig link against the
system libc when targeting the native C ABI. However this made it stop
putting libunwind.a on the linker line when it needed to sometimes,
causing undefined symbols when linking against C++ code.
The CPU detection code is nearly at feature parity, we do support
detecting the native CPU on Sparc systems and macos, our ARM/AArch64
model list is quite comprehensive and so is our PPC one.
The only missing pieces are:
- ARM32 detection on Darwin hosts (I don't think anybody is planning on
running the compiler on a old-ass iPhone)
- s390x detection on Linux hosts, this can be easily added at a later
stage.
Currently zig will always try to build its own libc and compile against
that. This of course makes sense for cross-compilation, but can cause
problems when targeting the native OS/ABI.
For example, if the system uses a newer glibc version than zig ships
zig will fall back to using the newest version it does ship. However
this causes linking system libraries to fail as they are built against a
different glibc version than the zig code is built against.
To remedy this, simply default to linking the system libc when targeting
the native OS/ABI.
Previously, I mistakenly assumed that offset of the relocation
is enough when calculating relative offset of the target from the
source target section base address in case of section-based relocs
on x86_64. While this is true for `__TEXT,__text` section which
always starts at 0x0 in object files, this is absolutely not true
for `__TEXT,__StaticInit` section which will have nonzero base
address hence resulting in incorrect displacement calculations for
SIGNED relocs.
