When any of the object files reference the __heap_end symbol, we will
create it as a synthetic symbol. The symbol only exists within the
linker and will not be emit within the binary as it's solely used for
relocations. The symbol represents where the heap ends, so allocators
can determine whether to allocate a new page or not.
The deallocations of the process arguments are unnecessary, since the
memory will be deallocated by arena.deinit().
The deallocations are incorrect, since ArgIterator.next() returns a
slice pointing to the iterator's internal buffer, that should be
deallocated with args_it.deinit().
When any object files provides an undefined reference to the __heap_base
symbol, we create a new defined symbol for it. During setupMemory we
set the virtual address of this symbol so it can be used for relocations.
This symbol represents where the heap starts and allocators can use
this value for its allocations when it needs to determine where the heap
lives.
This implements the `__wasm_call_ctors` symbol. This symbol is
automatically referenced by libc to initialize its constructors.
We first retrieve all constructors from each object file, and then
create a function body that calls each constructor based on its
priority. Constructors are not allowed to have any parameters, but are
allowed to have a return type. When a return type does exist, we simply
drop its value from the stack after calling the constructor to ensure
we pass the stack validator.
When emitting errors for undefined symbols, rather than
unconditionally always using the name from an import, we must verify
it's a symbol type that could have such an import. e.g. undefined
data symbols do not have a corresponding import. For this reason we
must use the regular name.
During symbol resolution when both symbols are undefined, we must
discard the new symbol with a reference to the existing symbol. This
ensures the original symbol remains undefined. This fixes symbol
resolution when linking with WASI-libC.
* Changed the interface to align with the new allocator interface.
* Fixed bug where not enough memory was allocated for the header or to
align the pointer.
The `zig build` command now makes `@import("@dependencies")` available
to the build runner package. It contains all the dependencies in a
generated file that looks something like this:
```zig
pub const imports = struct {
pub const foo = @import("foo");
pub const @"bar.baz" = @import("bar.baz");
};
pub const build_root = struct {
pub const foo = "<path>";
pub const @"bar.baz" = "<path>";
};
```
The build runner exports this import so that `std.build.Builder` can
access it. `std.build.Builder` uses it to implement the new `dependency`
function which can be used like so:
```zig
const libz_dep = b.dependency("libz", .{});
const libmp3lame_dep = b.dependency("libmp3lame", .{});
// ...
lib.linkLibrary(libz_dep.artifact("z"));
lib.linkLibrary(libmp3lame_dep.artifact("mp3lame"));
```
The `dependency` function calls the build.zig file of the dependency as
a child Builder, and then can be ransacked for its build steps via the
`artifact` function.
This commit also renames `dependency.id` to `dependency.name` in the
`build.zig.ini` file.
This allows setting a custom buffer size. In this case I wanted it
because using a buffer size large enough to fit a TLS ciphertext record
elides a memcpy().
This commit also adds `readAtLeast` to the Reader interface.
Some notable changes:
- `ENOENT` is returned instead of `ENOTCAPABLE` when a path has not
be pre-opened (https://github.com/WebAssembly/wasi-libc/pull/370)
- `fd_readdir()`: some implementations may not set the inode number,
so an additional call to `fstatat()` is now done in order to get it
when that happens.
