This caused zirParam instructions of parent blocks to be present in
inline analyzed blocks, and so function prototypes declared in the
inline blocks would also gain and add to the parameters in the
parent block.
Only block and block_inline are affected in this commit, as prototypes
and declarations are always generated in block_inline. This might need
to be resolved in a more general way at some point.
Previously, function parameter instructions for function prototypes would be
generated in the parent block. This caused issues in blocks where multiple
prototypes would be generated in, such as the block for struct fields for
example. This change introduces an inline block around every prototype such
that all parameters for a prototype are confined to a unique block.
This allows the inferred error set of comptime and inline invocations to be
resolved separately from the inferred error set of the runtime version or other
comptime/inline invocations.
* turns out MOV and other arithmetic instructions such as ADD can
naturally share the same lowering codepath (for the same variants)
* there are variants that are specific to ADD, or MOV which will be
implemented as standalone MIR tags
* tweak Isel tests to generate corresponding test cases for all
arithmetic instructions in comptime
* variant `0b11` when both `reg1 != .none` and `reg2 != .none` is
identical to `0b00` therefore it can safely be removed
* fix proper destination register size calculation when setting register from
another source register
* introduce `EmitResult` wrapper struct for easier manipulation of
intermediate emit results - this is mainly to track errors such as
size mismatch between operands
* create an informative `ErrorMsg` directly at the callsite
* ensure that every callsite of basic MOV MIR instruction follows the
Intel syntax (dst <- src)
* add extensive unit tests for MOV MIR -> Isel lowering
* leave TODOs for cases that are currently not handled and/or missing
* fix any ABI size mismatch between operands
Make `@returnAddress()` return for the BPF target, as the BPF target for
the time being does not support probing for the return address. Stack
traces for the general purpose allocator for the BPF target is also set
to not be captured.
The status quo for the `build.zig` build system is preserved in
the sense that, if the user does not explicitly override
`dylib.setInstallName(...);` in their build script, the default
of `@rpath/libname.dylib` applies. However, should they want to
override the default behaviour, they can either:
1) unset it with
```dylib.setIntallName(null);```
2) set it to an explicit string with
```dylib.setInstallName("somename.dylib");```
When it comes to the command line however, the default is not to
use `@rpath` for the install name when creating a dylib. The user
will now be required to explicitly specify the `@rpath` as part
of the desired install name should they choose so like so:
1) with `build-lib`
```
zig build-lib -dynamic foo.zig -install_name @rpath/libfoo.dylib
```
2) with `cc`
```
zig cc -shared foo.c -o libfoo.dylib -Wl,"-install_name=@rpath/libfoo.dylib"
```
Before this commit, glibc headers did the following mapping:
* (zig) mipsel-linux-gnu => (glibc) mipsel-linux-gnu
* (zig) mipsel-linux-gnu-soft => (glibc) (none)
* (zig) mips-linux-gnu => (glibc) mips-linux-gnu
* (zig) mips-linux-gnu-soft => (glibc) (none)
While the glibc ABI stubs used the (zig) gnueabi and gnueabihf ABIs,
and the stage2 available_libcs array listed:
* (zig) mipsel-linux-gnu
* (zig) mips-linux-gnu
The problem is the mismatch between the ABI component of the headers and
the stubs.
This commit makes the following clarifications:
* (zig) mips-linux-gnueabi means soft-float
* (zig) mipsel-linux-gnueabi means soft-float
* (zig) mips-linux-gnueabihf means hard-float
* (zig) mipsel-linux-gnueabihf means hard-float
Consequently, the glibc headers now do this mapping:
* (zig) mips-linux-gnueabihf => (glibc) mips-linux-gnu
* (zig) mipsel-linux-gnueabihf => (glibc) mipsel-linux-gnu
* (zig) mips-linux-gnueabi => (glibc) mips-linux-gnu-soft
* (zig) mipsel-linux-gnueabi => (glibc) mipsel-linux-gnu-soft
The glibc ABI stubs are unchanged, and the stage2 available_libcs
array's 2 entries are modified and it gains 2 more:
* (zig) mipsel-linux-gnueabi
* (zig) mipsel-linux-gnueabihf
* (zig) mips-linux-gnueabi
* (zig) mips-linux-gnueabihf
Now everything is consistent. Zig no longer recognizes a `mips-linux-gnu`
triple; one must use `mips-linux-gnueabi` (soft float) or
`mips-linux-gnueabihf` (hard float).
Upstream, some of the nonshared functions moved to be different for hurd
and for linux. Since our glibc is linux-only we update to use the
linux-specific files.
This fixes std lib tests for x86_64 when linking glibc.
This commit introduces tools/update_glibc.zig to update the start files
for next time.
Some notable changes in recent glibc:
* abi-note.S has been changed to abi-note.c but we resist the change to
keep it easier to compile the start files.
* elf-init.c has been deleted upstream. Further testing should be done
to verify that binaries against glibc omitting elf-init.c still run
properly on oldel glibc linux systems.
Closes#4926
Notating a symbol to be exported in code will only tell the linker
where to find this symbol, so other object files can find it. However, this does not mean
said symbol will also be exported to the host environment. Currently, we 'fix' this by force
exporting every single symbol that is visible. This creates bigger binaries and means host environments
have access to symbols that they perhaps shouldn't have. Now, users can tell Zig which symbols
are to be exported, meaning all other symbols that are not specified will not be exported.
Another change is we now support `-rdynamic` in the wasm linker as well, meaning all symbols will
be put in the dynamic symbol table. This is the same behavior as with ELF. This means there's a 3rd strategy
users will have to build their wasm binary.
While investigating slow build times with [a large project](https://github.com/hexops/mach/issues/124),
I found that the compiler was reading from disk nearly every C source file in my project
when rebuilding despite no changes having been made. This accounted for several seconds of
time (approx. 20-30% of running `zig build` without any changes to the sources.)
The cause of this was that comparisons of file mtimes would _always_ fail (the mtime of the file on
disk was always newer than that stored in the cache manifest), and so the cache logic would always
fall back to byte-for-byte file content comparisons with what is on disk vs. in the cache-reading every
C source file in my project from disk during each rebuild. Because file contents were the same, a cache
hit occurred, and _despite the mtime being different the cache manifest would not be updated._
One can reproduce this by building a Zig project so the cache is populated, and then changing mtimes
of their C source files to be newer than what is in the cache (without altering file contents.)
The fix is rather simple: we should always write the updated cache manifest regardless of
whether or not a cache hit occurred (a cache hit doesn't indicate if a manifest is dirty) Luckily,
`writeManifest` already contains logic to determine if a manifest is dirty and becomes no-op if no
change to the manifest file is necessary-so we merely need to ensure it is invoked.
Signed-off-by: Stephen Gutekanst <stephen@hexops.com>
This commit upgrades glibc shared library stub-creating code to use the
new abilists file which is generated by the new glibc-abi-tool project:
https://github.com/ziglang/glibc-abi-tool/
The abilists file is different in these ways:
* It additionally encodes whether a symbol is a function or an object,
and if it is an object, it additionally encodes the size in bytes.
* It additionally encodes migrations of symbols from one library to
another between glibc versions.
* It is binary data instead of ascii.
* It is one file instead of three.
* It is 165 KB instead of 200 KB.
This solves three bugs:
Fixes#7667Fixes#8714Fixes#8896
This way, we will inform the user that there are unresolved symbols
in addition to missing library/framework as requested on the linker
line. If all symbols were resolved on the other hand, we still
flag up that the library/framework cannot be found.
Example behaviour:
```
$ zig cc hello.c -framework MyFoundation --verbose
warning(link): framework not found for '-framework MyFoundation'
warning(link): Framework search paths:
warning(link): /Library/Frameworks
warning(link): /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/System/Library/Frameworks
thread 1079397 panic: attempt to unwrap error: FrameworkNotFound
...stack trace...
```
and
```
❯ zig cc hello.c -lWAT --verbose
warning(link): library not found for '-lWAT'
warning(link): Library search paths:
warning(link): /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib
warning(link): /usr/local/lib
thread 1079824 panic: attempt to unwrap error: LibraryNotFound
...stack trace...
```
We now respect both `-fallow-shlib-undefined` and
`-Wl,"-undefined=dynamic_lookup"` flags. This is the first step
towards solving issues #8180 and #3000. We currently do not expose
any other ld64 equivalent flag for `-undefined` flag - we basically
throw an error should the user specify a different flag. Support for
those is conditional on closing #8180. As a result of this change,
it is now possible to generate a valid native Node.js addon with Zig
for macOS.
