Tested by: created a "hello world" C file and compiled with:
zig cc -v main.c -Wl,--sort-section=name -o main
... and verified the `--sort-section=name` is passed to ld.lld.
Refs https://github.com/zigchroot/zig-chroot/issues/1
This is just a simple/hacky feature to report the source of a linking
error. I found this helpful in fixing-up some of my libs when recently
switching from an x86_64 to aarch64 device, so thought it might be
useful to others a well before zld has a fully featured error reporting
system.
There can be a maximum of 256 compact encodings per page in compact
unwind info, and we were using `u8` to represent the count which is insufficient.
This commit bumps it to `u9`.
This finishes the work started in #14502 where atoms are owned by the
linker themselves. This now makes debug atoms fully owned by dwarf,
and no information is left stored on the decl.
These functions are currently footgunny when working with pointers to
arrays and slices. They just return the stated length of the array/slice
without iterating and looking for the first sentinel, even if the
array/slice is a sentinel terminated type.
From looking at the quite small list of places in the standard
library/compiler that this change breaks existing code, the new code
looks to be more readable in all cases.
The usage of std.mem.span/len was totally unneeded in most of the cases
affected by this breaking change.
We could remove these functions entirely in favor of other existing
functions in std.mem such as std.mem.sliceTo(), but that would be a
somewhat nasty breaking change as std.mem.span() is very widely used for
converting sentinel terminated pointers to slices. It is however not at
all widely used for anything else.
Therefore I think it is better to break these few non-standard and
potentially incorrect usages of these functions now and at some later
time, if deemed worthwhile, finally remove these functions.
If we wait for at least a full release cycle so that everyone adapts to
this change first, updating for the removal could be a simple find and
replace without needing to worry about the semantics.
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.
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.
