This implements `@export(a.b, .{..});` in semantic analysis,
allowing users to directly export a variable from a namespace.
* add test case for exporting using field access
Without the packed qualifier, the type layout that we use to
initialize doesn't match the correct layout of the underlying
storage, causing corrupted data and past-the-end writes.
When testing the Wasm linker for the producers section
we do not ever want to strip the binary as this will remove
the producers section in release-small.
This fixes the CI errors by d086b371f0e21e5029e1b0d05838b87502eb63e6
Thanks to Martin Storsjö for explaining this to me on IRC:
__USE_MINGW_ANSI_STDIO redirects stdio functions towards mingw-w64
reimplementations of them (since msvcrt.dll lacks lots of things). For
x86 with "long double", this is also needed to get long doubles
formatted properly. It's enabled by default by headers when building in
C99 mode, unless you're targeting UCRT. The headers normally enable this
automatically - or you can request it enabled with
-D__USE_MINGW_ANSI_STDIO=1. However, the mingw-w64-crt files are
expected to be built with this explicitly turned off. Since there's a
half dozen various ways of configuring the CRT and various features, the
mingw-w64-crt files specifically need to be built in a very hardcoded
configuration, which is different from how end user source files are
compiled.
This commit removes a patch that we were carrying previously.
See #7356
These tests will be failing on many platforms until #8465 is resolved.
Luckily, the particular function signature used for __divXc3 and __mulXc3
seems to be OK on x86-64.
These are the standard complex multiplication/division functions
required by the C standard (Annex G).
Don't get me started on the standard's handling of complex-infinity...
This re-write was needed to fix deficiencies in the existing ldexp,
which was failing to compute correct results for both f16 and f80.
It would be nice to add a fast multiplication-based fallback in the
future for targets that have a hardware FPU, but this implementation
should be much faster than the existing for targets without one.
Addends in relocations are signed integers as theoretically it could
be a negative number. As Atom's offsets are relative to their parent
section, the relocation value should still result in a postive number.
For this reason, the final result is stored as an unsigned integer.
Also, rather than using `null` for relocations that do not support
addends. We set the value to 0 for those that do not support addends,
and have to call `addendIsPresent` to determine if an addend exists
or not. This means each Relocation costs 4 bytes less than before,
saving memory while linking.
This also turns off non-debug modes for the bss linker tests for
Wasm. This is done as it's not required to guarantee to zero out
the bss section for non-debug modes.
The `producers` section contains meta data of the binary and/or
object file. It *can* contain the source language, the tool it
was processed by, and/or the SDK that was used to produce the file.
For now, we always set the language and processed-by fields to Zig.
In the future we will parse linked object files to detect their
producers sections and append (if different) their language, SDK
and processed-by fields.
