Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

give BSDs some attention #13699

Merged
merged 15 commits into from
Jan 3, 2023
Merged

give BSDs some attention #13699

merged 15 commits into from
Jan 3, 2023

Conversation

mikdusan
Copy link
Member

@mikdusan mikdusan commented Nov 29, 2022

  • make general progress on tier-2 BSDs
  • there may be some minor patches for macOS and others included

closes #13700

please see status/details in #13700

@semarie
Copy link
Contributor

semarie commented Dec 3, 2022

FYI, openbsd build work well with the diff, and tests are still passing.

@theoparis
Copy link

theoparis commented Dec 27, 2022

Is it just me or does building this PR cause an entire 64 gb of swap to be used when compiling stage3 (build-host-zig) with zig-bootstrap 🤔

I tried to use zig bootstrap but I replaced the zig folder with your bsd branch and it seems to be causing this massive memory leak.

lib/std/os.zig Outdated Show resolved Hide resolved
lib/std/os.zig Outdated Show resolved Hide resolved
@mikdusan
Copy link
Member Author

mikdusan commented Dec 28, 2022

Is it just me or does building this PR cause an entire 64 gb of swap to be used when compiling stage3 (build-host-zig) with zig-bootstrap 🤔

It's not just you! Trying to narrow down what is causing this. Strange tho, I am able to manually use the ld.lld args with BOTH zig ld.lld and even my dep llvm toolchain's ld.lld and linking succeeds without eating up huge GB's.

update: I threw out the mission-creep of linking to system c++ via regular -l options and thus the massive memory grab doesn't manifest anymore

@mikdusan mikdusan force-pushed the bsd branch 2 times, most recently from 17430f0 to 1277900 Compare December 30, 2022 21:44
@mikdusan mikdusan marked this pull request as ready for review December 30, 2022 21:44
@semarie
Copy link
Contributor

semarie commented Dec 31, 2022

@mikdusan do you think that PR could be splitted and commits incrementally done (instead of pushing all in one big PR) ?

currently, several OS are broken waiting for only some commits in this PR (like "avoid Dir.realpathAlloc").

having a good BSD support is a very good target (and thanks for your work on it), but I would be glad to have a working compiler too.

@mikdusan
Copy link
Member Author

@mikdusan do you think that PR could be splitted and commits incrementally done (instead of pushing all in one big PR) ?

I'd like to get a review from andrew first. But yeah if it makes some pieces land faster, I'm open to splitting things up.

Copy link
Member

@andrewrk andrewrk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for giving some attention to the BSDs. In particular you have made me realize that a problematic commit has been residing in master branch for quite some time, which I have reverted.

I left a few review comments, but with those resolved, this changeset looks ready to merge to me.

src/main.zig Outdated Show resolved Hide resolved
CMakeLists.txt Outdated Show resolved Hide resolved
lib/libcxx/include/__config Show resolved Hide resolved
src/Compilation.zig Outdated Show resolved Hide resolved
- first convert to lower-case then perform mappings
- effect: freebsd, netbsd and openbsd convert arch `amd64` to `x86_64`
- effect: convert `arm64` to `aarch64`
- per darwin-xnu source, fcntl F_GETPATH will return ENOSPC when path
  exceeds either user-supplied buffer or system MAXPATHLEN
- macOS does not document this (and other) possible errno values
- add conditional compile error
- add conditional skip test
- freebsd, netbsd, openbsd, dragonfly
- add netbsd
- add dragonfly
- fixup freebsd
This allows for a more optimal std.crypto.tlcsprng codepath.

Without it a an "incorrect alignment" panic is triggered from
crypto.tlcsprng which aligns a threadlocal but it's actually
not aligned, thus detected by the safety check.

It appears that LLVM-IR does attribute the storage with alignment
but it is ultimately not respected in the final binary for netbsd
and dragonfly.
@andrewrk andrewrk merged commit 8bd734d into ziglang:master Jan 3, 2023
@andrewrk
Copy link
Member

andrewrk commented Jan 3, 2023

Great work, thank you very much!

@mikdusan mikdusan deleted the bsd branch January 5, 2023 22:33
andrewrk added a commit that referenced this pull request Jan 9, 2023
give BSDs some attention
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

give BSDs some attention
5 participants