| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
make the fuzzer vaguely work on macOS
|
|
Elf2: more progress
|
|
Like ELF, we now have `std.debug.MachOFile` for the host-independent
parts, and `std.debug.SelfInfo.MachO` for logic requiring the file to
correspond to the running program.
|
|
|
|
This is the logic that LLD uses. It is pretty silly, but it is what it is.
|
|
aarch64-ios-macabi
Apple's own headers and tbd files prefer to think of Mac Catalyst as a distinct
OS target. Earlier, when DriverKit support was added to LLVM, it was represented
a distinct OS. So why Apple decided to only represent Mac Catalyst as an ABI in
the target triple is beyond me. But this isn't the first time they've ignored
established target triple norms (see: armv7k and aarch64_32) and it probably
won't be the last.
While doing this, I also audited all Darwin OS prongs throughout the codebase
and made sure they cover all the tags.
|
|
I started this diff trying to remove a little dead code from the C
backend, but ended up finding a bunch of dead code sprinkled all over
the place:
* `packed` handling in the C backend which was made dead by `Legalize`
* Representation of pointers to runtime-known vector indices
* Handling for the `vector_store_elem` AIR instruction (now removed)
* Old tuple handling from when they used the InternPool repr of structs
* Straightforward unused functions
* TODOs in the LLVM backend for features which Zig just does not support
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Move/coalesce `CompressDebugSections` and `RcIncludes` enums to `std.zig`
|
|
ld.lld fails with "truncated or malformed archive" errors when reading
archive header field values that are not valid numbers.
|
|
|
|
Also updates the field names to conform with the rest of std.
|
|
OpSource (#25435)
* fixing Zig generator magic in SPIR-V header; adding zig compiler version to SPIR-V OpSource
* Update src/codegen/spirv/Module.zig
Co-authored-by: rpkak <67059904+rpkak@users.noreply.github.com>
---------
Co-authored-by: rpkak <67059904+rpkak@users.noreply.github.com>
|
|
Elf2: start implementing input object loading
|
|
`std.Io.tty.Config.detect` may be an expensive check (e.g. involving
syscalls), and doing it every time we need to print isn't really
necessary; under normal usage, we can compute the value once and cache
it for the whole program's execution. Since anyone outputting to stderr
may reasonably want this information (in fact they are very likely to),
it makes sense to cache it and return it from `lockStderrWriter`. Call
sites who do not need it will experience no significant overhead, and
can just ignore the TTY config with a `const w, _` destructure.
|
|
Closes #25565
|
|
|
|
|
|
|
|
|
|
|
|
std: Introduce `Io` Interface
|
|
As with Solaris (dba1bf935390ddb0184a4dc72245454de6c06fd2), we have no way to
actually audit contributions for these OSs. IBM also makes it even harder than
Oracle to actually obtain these OSs.
closes #23695
closes #23694
closes #3655
closes #23693
|
|
only thing remaining is using libc dns resolution when linking libc
|
|
compiler toolchains have no business knowing what time it is
|
|
|
|
|
|
There is no straightforward way for the Zig team to access the Solaris system
headers; to do this, one has to create an Oracle account, accept their EULA to
download the installer ISO, and finally install it on a machine or VM. We do not
have to jump through hoops like this for any other OS that we support, and no
one on the team has expressed willingness to do it.
As a result, we cannot audit any Solaris contributions to std.c or other
similarly sensitive parts of the standard library. The best we would be able to
do is assume that Solaris and illumos are 100% compatible with no way to verify
that assumption. But at that point, the solaris and illumos OS tags would be
functionally identical anyway.
For Solaris especially, any contributions that involve APIs introduced after the
OS was made closed-source would also be inherently more risky than equivalent
contributions for other proprietary OSs due to the case of Google LLC v. Oracle
America, Inc., wherein Oracle clearly demonstrated its willingness to pursue
legal action against entities that merely copy API declarations.
Finally, Oracle laid off most of the Solaris team in 2017; the OS has been in
maintenance mode since, presumably to be retired completely sometime in the 2030s.
For these reasons, this commit removes all Oracle Solaris support.
Anyone who still wishes to use Zig on Solaris can try their luck by simply using
illumos instead of solaris in target triples - chances are it'll work. But there
will be no effort from the Zig team to support this use case; we recommend that
people move to illumos instead.
|
|
Only supported in CBE.
|
|
Only supported in CBE.
|
|
Supported by LLVM and CBE.
|
|
|
|
Only for use with the C backend at the moment.
|
|
|
|
This path being relative is unconventional and causes issues for us
if the output artifact is ever used from a different cwd than the one it
was built from. The behavior implemented by this commit of always
emitting these paths as absolute was actually the behavior in 0.14.x,
but it regressed in 0.15.1 due to internal reworks to path handling
which led to relative paths being more common in the compiler internals.
Resolves: #25433
|
|
Related to 1d764c1fdf04829cec5974d82cec901825a80e49
Test case provided by:
Co-authored-by: Kendall Condon <goon.pri.low@gmail.com>
|
|
This allows segments to be moved around in the output file without
needing to reapply relocations until virtual address space is exhaused.
|
|
|
|
|
|
Resolves: https://github.com/ziglang/zig/issues/24993
|
|
|
|
We mustn't emit the DT_PLTGOT entry in `.dynamic` in a statically-linked
PIE, because there's no dl to relocate it (and `std.pie.relocate`, or
the PIE relocator in libc, won't touch it). In that case, there cannot
be any PLT entries, so there's no point emitting the `.got.plt` section
at all. If we just don't create that section, `link.Elf` already knows
not to add the DT_PLTGOT entry to `.dynamic`.
Co-authored-by: Jacob Young <jacobly0@users.noreply.github.com>
|
