| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes #8096.
|
|
* Accept -fsanitize-c=trap|full in addition to the existing form.
* Accept -f(no-)sanitize-trap=undefined in zig cc.
* Change type of std.Build.Module.sanitize_c to std.zig.SanitizeC.
* Add some missing Compilation.Config fields to the cache.
Closes #23216.
|
|
These deal with how Zig stores OS headers in `lib/libc/include` and so don't
really belong in std.Target.
|
|
crti.o/crtn.o is a legacy strategy for calling constructor functions
upon object loading that has been superseded by the
init_array/fini_array mechanism.
Zig code depends on neither, since the language intentionally has no way
to initialize data at runtime, but alas the Zig linker still must
support this feature since popular languages depend on it.
Anyway, the way it works is that crti.o has the machine code prelude of
two functions called _init and _fini, each in their own section with the
respective name. crtn.o has the machine code instructions comprising the
exitlude for each function. In between, objects use the .init and .fini
link section to populate the function body.
This function is then expected to be called upon object initialization
and deinitialization.
This mechanism is depended on by libc, for example musl and glibc, but
only for older ISAs. By the time the libcs gained support for newer
ISAs, they had moved on to the init_array/fini_array mechanism instead.
For the Zig linker, we are trying to move the linker towards
order-independent objects which is incompatible with the legacy
crti/crtn mechanism.
Therefore, this commit drops support entirely for crti/crtn mechanism,
which is necessary since the other commits in this branch make it
nondeterministic in which order the libc objects and the other link
inputs are sent to the linker.
The linker is still expected to produce a deterministic output, however,
by ignoring object input order for the purposes of symbol resolution.
|
|
|
|
this strategy uses a "postponed" queue to handle codegen tasks that
spawn too early. there's probably a better way.
|
|
This is necessary since isGnuLibC() is true for hurd, so we need to be able to
represent a glibc version for it.
Also add an Os.TaggedVersionRange.gnuLibCVersion() convenience function.
|
|
This is already handled by build_crt_file().
|
|
This option, by its very nature, needs to be attached to a module. If it isn't,
the code in a module could break at random when compiled into an application
that doesn't have this option set.
After this change, skip_linker_dependencies no longer implies no_builtin in the
LLVM backend.
|
|
|
|
|
|
addCCArgs() will then pass the appropriate flag to Clang.
|
|
The old isARM() function was a portability trap. With the name it had, it seemed
like the obviously correct function to use, but it didn't include Thumb. In the
vast majority of cases where someone wants to ask "is the target Arm?", Thumb
*should* be included.
There are exactly 3 cases in the codebase where we do actually need to exclude
Thumb, although one of those is in Aro and mirrors a check in Clang that is
itself likely a bug. These rare cases can just add an extra isThumb() check.
|
|
This fixes an X86_64_32 relocation linker error when targeting gnux32.
|
|
these tasks have some shared data dependencies so they cannot be done
simultaneously. Future work should untangle these data dependencies so
that more can be done in parallel.
for now this commit ensures correctness by making linker input parsing
and codegen tasks part of the same queue.
|
|
|
|
|
|
Ideally we'd like to use whatever alignment glibc actually ends up using in the
real libc.so.6. But we don't really have a way of getting at that information at
the moment, and it's not present in the abilist files. I haven't yet seen a
symbol that wasn't word-aligned, though, so I think this should be good enough
for 99% of symbols, if not actually 100%.
|
|
This prevents LLVM from...cleverly...merging all of the global variable stub
symbols that we emit under certain circumstances. This was observed in practice
when using zig-bootstrap for arm-linux-gnueabi(hf).
|
|
Embrace the Path abstraction, doing more operations based on directory
handles rather than absolute file paths. Most of the diff noise here
comes from this one.
Fix sorting of crtbegin/crtend atoms. Previously it would look at all
path components for those strings.
Make the C runtime path detection partially a pure function, and move
some logic to glibc.zig where it belongs.
|
|
|
|
Closes #20376.
Closes #21076.
|
|
|
|
|
|
|
|
|
|
|
|
libc_nonshared.a.
Apparently 3fb6e46f6e4231b9569193a15a4357a2ae11fb0f wasn't enough.
|
|
Closes #20919.
|
|
We no longer expose `thumb*-linux-gnueabi*` target triples in std.zig.target.
|
|
This is necessary to inform the real, non-stub glibc that a program built with
Zig is using a modern `FILE` structure, i.e. glibc 2.1+. This is particularly
important on lesser-used architectures where the legacy code is poorly tested;
for example, glibc 2.40 introduced a regression for the legacy case in the
libio cleanup code, causing all Zig-compiled MIPS binaries to crash on exit.
|
|
For some platforms, the math-related flags are ignored and produce warnings.
There's nothing we can do about that, so just silence them.
|
|
loongarch64-linux-gnu (#21015)
|
|
|
|
Support building glibc for riscv32/riscv64
|
|
`std.Target`: Minor rework to some `isArch()` functions, fix some related issues throughout `std`
|
|
This reverts commit 62a01851d9c433ea3f2e98cc986e75d32aece443.
No longer needed with the abilists update.
|
|
~Same thing as b03a04c7fca587af0f1caf59881def3c91596728.
|
|
|
|
|
|
Revert this commit on the next glibc abilists update.
|
|
What is `sparcel`, you might ask? Good question!
If you take a peek in the SPARC v8 manual, §2.2, it is quite explicit that SPARC
v8 is a big-endian architecture. No little-endian or mixed-endian support to be
found here.
On the other hand, the SPARC v9 manual, in §3.2.1.2, states that it has support
for mixed-endian operation, with big-endian mode being the default.
Ok, so `sparcel` must just be referring to SPARC v9 running in little-endian
mode, surely?
Nope:
* https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/llvm/lib/Target/Sparc/SparcTargetMachine.cpp#L226
* https://github.com/llvm/llvm-project/blob/40b4fd7a3e81d32b29364a1b15337bcf817659c0/llvm/lib/Target/Sparc/SparcTargetMachine.cpp#L104
So, `sparcel` in LLVM is referring to some sort of fantastical little-endian
SPARC v8 architecture. I've scoured the internet and I can find absolutely no
evidence that such a thing exists or has ever existed. In fact, I can find no
evidence that a little-endian implementation of SPARC v9 ever existed, either.
Or any SPARC version, actually!
The support was added here: https://reviews.llvm.org/D8741
Notably, there is no mention whatsoever of what CPU this might be referring to,
and no justification given for the "but some are little" comment added in the
patch.
My best guess is that this might have been some private exercise in creating a
little-endian version of SPARC that never saw the light of day. Given that SPARC
v8 explicitly doesn't support little-endian operation (let alone little-endian
instruction encoding!), and no CPU is known to be implemented as such, I think
it's very reasonable for us to just remove this support.
|
|
|
|
writeFile was deprecated in favor of writeFile2 in f645022d16361865e24582d28f1e62312fbc73bb. This commit renames writeFile2 to writeFile and makes writeFile2 a compile error.
|
|
Rather than an ArrayList. Provides deduplication.
|
|
|
|
Previously, when multiple modules had builtin modules with identical
sources, two distinct `Module`s and `File`s were created pointing at the
same file path. This led to a bug later in the frontend. These modules
are now deduplicated with a simple hashmap on the builtin source.
|
|
part of #19063
This is a prerequisite for doing the same for Resinator.
|
|
At a minimum required glibc is v2.17, as earlier versions do not define
some symbols (e.g., getauxval()) used by the Zig standard library.
Additionally, glibc only supports some architectures at more recent
versions (e.g., riscv64 support came in glibc v2.27). So add a
`glibc_min` field to `available_libcs` for architectures with stronger
version requirements.
Extend the existing `canBuildLibC` function to check the target against
the Zig minimum, and the architecture/os minimum.
Also filter the list shown by `zig targets`, too:
$ zig targets | jq -c '.glibc'
["2.17.0","2.18.0","2.19.0","2.20.0","2.21.0","2.22.0","2.23.0","2.24.0","2.25.0","2.26.0","2.27.0","2.28.0","2.29.0","2.30.0","2.31.0","2.32.0","2.33.0","2.34.0","2.35.0","2.36.0","2.37.0","2.38.0"]
Fixes #17034
Fixes #17769
|
