This updates the C backend to use proper array types.
In order to do that, this commit also:
- fixes up elem_ptr and field_ptr handling
- adds `renderTypecast` (renders in C typecast format, e.g. "int* [10]")
- adds a bit special handling for undefined pointers, which is necessary
to support slice/elem_ptr to undefined decls
Now, the abstracted stack offsets grow in the same direction as
the real stack values in hardware, and allocating stack memory is done
by the taking the last stack offset, adding required abi size
and aligning to the required abi align. Stack handling is now more
natural as it aligns itself with how it works in hardware; hence
stepping through the debugger and printing out different stack
values is intuitive. Finally, the stack pointers are now correctly
aligned to the required (and not necessarily natural) alignment.
* move DWARF in file if LINKEDIT spilled in dSYM
* update VM addresses for all segments
* introduce copyFileRangeOverlappedAll instead of File.copyRangeAll
since we make lots of overlapping writes in MachO linker
This "feature" of gcc/clang means to treat this as a positional
link object, but using the library search directories as a prefix.
We solve this problem in the CLI layer, using a separate map for
the data since it is an uncommon case.
Closes#10851
* update number of type abbrevs to match Elf linker
* update `DebugSymbols` to write symbol and string tables
at the end to match the `MachO` linker
* TODO: update segment vm addresses when growing segments in
the binary
* TODO: store DWARF relocations in linker's interned arena
The information whether a register is allocated to an instruction is
already encoded in the free_registers "bitmap". Duplicating that
information in the registers map is unnecessary and may lead to
performance degradations.
Big-int functions were updated to respect the provided abi_size, rather
than inferring a potentially incorrect abi_size implicitly.
In combination with the convention that any required padding bits are
added on the MSB end, this means that exotic integers can potentially
have a well-defined memory layout.
Due to differences in where the output gets emitted in stage1 and stage2,
we were putting the symlink next to the binary rather than in `zig-cache`
directory when building with stage2.
LLVM doesn't support lowering union values, so we have to use unnamed
structs to do it, which means any type that contains a union as an
element, even if it is nested in another type, has to have a mechanism
to detect when it can't be lowered normally and has to resort itself to
an unnamed struct.
This includes arrays.
Comment reproduced here:
Note the following u64 alignments:
x86-linux: 4
x86-windows: 8
LLVM makes x86_fp80 have the following alignment and sizes regardless
of operating system:
x86_64: size=16, align=16
x86: size=12, align=4
However in Zig we override x86-windows to have size=16, align=16
in order for the property to hold that u80 and f80 have the same ABI size.
Fixes "error: destination type 'f80' has size 12 but source type 'u80'
has size 16" when trying to bitcast between f80 and u80 on i386-windows.
