Skip to content

Omnibus to get a clean OpenBSD build. #3003

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

Merged
merged 9 commits into from
Jul 14, 2021

Conversation

3405691582
Copy link
Member

This pr includes a few changes -- not including runloop changes which will be in a different pr -- to get a clean Foundation build on OpenBSD. Both this pr and the runloop changes are required for Foundation to build properly, work, and pass tests on this platform.

Please feel free to request any or all to be split into multiple prs.

Of note:

  • a simple routine to search the runtime PATH to avoid having to specify the full binary name in the environment (kernel support to determine the full binary path on this platform is not present)
  • supplying an implementation for FileManager+POSIX
  • XFAIL'ing a few tests that rely on backtrace support
  • handling some missing symbols and other minor API differences

x86_64 is spelled "amd64" on this platform. Return "amd64", for
consistency with Swift and other projects.
See e.g., LibcOverlayShims.h in Swift.
Don't try to unconditionally use it. I don't know if this has any
untoward side effects but running tests seems to be generally OK.
@spevans
Copy link
Contributor

spevans commented Jul 10, 2021

@swift-ci test

}
}
}

Copy link
Contributor

Choose a reason for hiding this comment

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

Would this have issues if the executable was specified using a relative path ,eg ../some_executable ? It would fail the first check but not necessarily be in the PATH

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes, that would not work if the realpath call failed and we fell back to argv[0]. We can call realpath a second time to ensure we get an absolute path. Added missing free calls as well.

@spevans
Copy link
Contributor

spevans commented Jul 10, 2021

@swift-ci test

@3405691582
Copy link
Member Author

Addressed the relative path issue, also amended a small cmake change that I missed earlier.

@spevans
Copy link
Contributor

spevans commented Jul 10, 2021

@swift-ci test

@spevans
Copy link
Contributor

spevans commented Jul 11, 2021

@swift-ci test linux

while ((p = strsep(&paths, ":")) != NULL) {
char pp[PATH_MAX];
snprintf(pp, PATH_MAX, "%s/%s", p, argv0);
char *res = realpath(pp, NULL);
Copy link
Contributor

Choose a reason for hiding this comment

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

if snprintf returns >= PATH_MAX the path in pp will be truncated and thus invalid.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's fine, if the path to the binary is going to be too long, we will truncate and when we try and see if the truncated file exists, we'll get an error and we'll fall out of this case. Although, did you have an alternative suggestion in mind?

Copy link
Contributor

Choose a reason for hiding this comment

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

The truncated name could still be another valid executable on the filesystem, I would suggest just treating the truncation the same way the realpath failure is treated.

Copy link
Member Author

Choose a reason for hiding this comment

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

Good point! Fixed.

free(res);
}
free(argv0);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Could you just tidy up the formatting in this if block so its all consistent at 4 space indent, thanks.

Copy link
Member Author

Choose a reason for hiding this comment

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

Oops -- sorry about that. Fixed.

There is no native mechanism to get the running process path on OpenBSD.
Currently, the shell needs to cooperate and fill in the path. This
works, but not all shells set the `_` environment variable.

We however are able to get `argv[0]` via sysctl on this platform.
Instead of just trying `_` and then giving up otherwise, first try
getting `argv[0]`. If that appears to be an absolute path, then we can
likely assume that this is what we need; otherwise, search PATH.

On other BSD platforms, this sysctl may need to be modified or an
alternative mechanism supplied to get `argv[0]`, so we still fallback on
`getenv("_")`.
These may be better handled by some other mechanism, but for now, make
these changes to get a clean compile:

* getnameinfo on BSD takes a `size_t` for the host name,
  not a `socklen_t`.

* PTHREAD_MUTEX_RECURSIVE is part of an enum on OpenBSD, so requires
  `.rawValue`.

* Like on Android, SOCK_STREAM and SOCK_DGRAM are not enums.
  INADDR_LOOPBACK is a complex macro, so requires defining the flattened
  the value (this is of course brittle, but is the best option for now).
There is libexecinfo as a 3rd-party package, but don't expect it be
available for now. This requires removing the -fexeceptions flag
on this platform also.

While we are doing this, introduce the necessary boilerplate to mark
tests as expected failures.
OpenBSD doesn't support these particular errno symbols. Exclude them for
this platform.
The mac OS implementation is close to what is required for OpenBSD but
requires tweaking. Instead of trying to unify the two implementations
with #if branches, just riff off the mac OS implementation and create a
new platform specific implementation.
Add the relevant routines for getting and setting thread name in
CFPlatform.

While we are doing this, change an #if branch in CFStream to set thread
name to using the actual routines declared in CFPlatform to do this.
@spevans
Copy link
Contributor

spevans commented Jul 13, 2021

@swift-ci test

2 similar comments
@spevans
Copy link
Contributor

spevans commented Jul 14, 2021

@swift-ci test

@spevans
Copy link
Contributor

spevans commented Jul 14, 2021

@swift-ci test

@spevans spevans merged commit d0011ab into swiftlang:main Jul 14, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants