By default we garbage-collect sections for Wasm to reduce size, as well
as finish linking quicker (as we have fewer things to do). However,
when the user specifies `--no-gc-sections` we ensure all resolved symbols
get marked and therefore do not get garbage collected.
This is supported in both incremental-mode and traditional linking.
When using the Wasm backend, we will now also perform garbage collection
there, to ensure unreferenced symbols do not get parsed nor emit into
the final binary.
When we encounter a debug info symbol, we initially have to parse it
into an atom to find its relocations. We then go through its relocations
to find out if any of the target symbols are marked alive. When it
finds an alive symbol, we also mark the debug symbol as alive to ensure
this piece of debug info is emit to the binary. When it does not encounter
any alive symbols, the debug symbol remains dead and will be garbage-
collected during `allocateAtoms`.
When multiple symbols point to the same function, we ensure any
other symbol other than the original will be discarded and point
to the original instead. This prevents emitting the same function
code more than once.
Rather than parsing every symbol into an atom, we now only parse them
into an atom when such atom is marked. This means garbage-collected
symbols will also not be parsed into atoms, and neither are discarded
symbols which have been resolved by other symbols. (Such as multiple
weak symbols).
This also introduces a binary search for finding the start index into
the list of relocations. This speeds up finding the corresponding
relocations tremendously as they're ordered ascended by address.
Lastly, we re-use the memory of atom's data as well as relocations
instead of duplicating it. This means we half the memory usage of
atom's data and relocations for linked object files. As we are
aware of decls and synthetic atoms, we free the memory of those
atoms indepedently of the atoms of object files to prevent double-frees.
Symbols which are exported to the host, or contain the `NO_STRIP`
flag, will be marked. All symbols which are referenced by this symbol
are marked likewise. We achieve this by parsing all relocations of a
symbol, and then marking the symbol it points to within the relocation.
When a linked object contains references to the __tls_base symbol,
we lazily create this symbol. However, we wouldn't create the corresponding
Wasm global. This meant its address wasn't set correctly as well as fail
to output it into the `Names` section.
The logic here already caught the case when a dependency path tried to
escape out of the zig cache directory using up directories. However, it
did not catch the case when the relative path tried to reach into a
different path within the zig-cache. For example, if it asked for
"../../../blah" then it would be caught, but if it asked for "../blah"
then it would try to resolve as "zig-cache/p/blah" and probably result
in file-not-found, or perhaps resolve to a different package if someone
inadvertently used a valid package hash instead of "blah".
Now it correctly gives a "dependency path outside project" error,
however, still allows relative paths with up-dirs that were not fetched
via URL.
reads on eg. connected TCP sockets can fail with ETIMEDOUT, and ENOTCONN
happens eg. if you try to read a TCP socket that has not been connected
yet.
interestingly read() was already handling CONNRESET & TIMEDOUT, but
readv(), pread(), and preadv() were somewhat inconsistent.
This duplicates the source file string (as is done in other places such
as `addAssemblyFile()`) in order to prevent a segfault when the supplied
string is freed by the caller. This is still seen when the caller makes
use of a defer statement.
This reverts commit 8b10970836480a43a3bbb1276cb258c2a8b613f2.
This implementation has the following problems:
* It does not provide context to the less than function. This will be an
API break in order to fix.
* It uses recursion, causing unbounded stack memory usage - likely
depending on user input, which is extra problematic.
* Sorting linked lists is generally an inefficient operation;
encouraging it by having a standard library function for it may
lead to suboptimal software being written in Zig.
Furthermore, there is almost no benefit to providing a sort function as
a method, when a third party implementation can easily be passed a
linked list to then be sorted.
A parameter like this is not always optional, even if that is
usually implied. SPIR-V tools fail to parse a module with an
OpLoopMerge instruction where the loop control parameter is
left out.
