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

Merge darwin/libdispatch-1324.41.2 to main #583

Open
wants to merge 250 commits into
base: main
Choose a base branch
from

Conversation

rokhinip
Copy link
Contributor

@rokhinip rokhinip commented Nov 6, 2021

Merge tag darwin/libdispatch-1324.41.2 on darwin/trunk.

This includes the latest Apple source drop libdispatch-1324.41.2 (up from libdispatch-1121) on top of darwin/libdispatch-1121 (merged in #447)

rokhinip and others added 30 commits November 5, 2021 16:32
Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
This is needed for proper shared linkage to the BlocksRuntime (e.g. when
building SourceKit).  We now build BlocksRuntime shared or static as requested.

Signed-off-by: Kim Topley <ktopley@apple.com>
build: honour `BUILD_SHARED_LIBS`
Signed-off-by: Kim Topley <ktopley@apple.com>
Adjust the build for Windows to permit the isa pointer to successfully
link.  They will be off by a level of indirection and need to be patched
up at runtime.

Signed-off-by: Kim Topley <ktopley@apple.com>
Windows BlocksRuntime

Signed-off-by: Kim Topley <ktopley@apple.com>
…overlay.

Because we are linking libdispatch through clang rather than swift, we need to
explicitly add swiftrt.o, which is needed by ELF and COFF to register metadata
sections. Fixes rdar://problem/44941707.

Signed-off-by: Kim Topley <ktopley@apple.com>
[CMake] Make sure to link swiftrt.o when building the Swift Dispatch overlay.

Signed-off-by: Kim Topley <ktopley@apple.com>
This fixes an error from the swift compiler:
	error: cannot convert value of type 'UInt32' to expected argument type 'UInt'

Signed-off-by: Kim Topley <ktopley@apple.com>
swift: cast to the appropriate type
Signed-off-by: Kim Topley <ktopley@apple.com>
queue: clean up a covered switch
Signed-off-by: Kim Topley <ktopley@apple.com>
This unblocks building on 32-bit Linux using the i686 triple.

Signed-off-by: Kim Topley <ktopley@apple.com>
Linux i686 Build Support

Signed-off-by: Kim Topley <ktopley@apple.com>
This function is declared as accepting a `dispatch_function_t` callback, which
is a function pointer with a `void *` argument. However, the implementation and
Swift overlay declare the callback without arguments, causing a conflict which
Clang warns about. Change the function signature to accept the correct type.

Signed-off-by: Kim Topley <ktopley@apple.com>
Fix the signature of _dispatch_install_thread_detach_callback()

Signed-off-by: Kim Topley <ktopley@apple.com>
Use the exported target from swift rather than recreate the paths locally.  This
almost works to replace the use of the paths.  Unfortunately, swiftrt is not
currently exported.

Signed-off-by: Kim Topley <ktopley@apple.com>
build: support static builds for Swift
Signed-off-by: Kim Topley <ktopley@apple.com>
dispatch_c99: remove unnecessary __printflike() definition

Signed-off-by: Kim Topley <ktopley@apple.com>
Change from a symlink to a copy.  This is more portable and fixes the
distribution aspect.  When the installation occurs, the symbolic link is
not followed and a symbolic link is installed.  Rather if we copy, we
can get the contents.  The files are small so the cost is relatively
low.

Signed-off-by: Kim Topley <ktopley@apple.com>
build: always copy the modulemaps
Signed-off-by: Kim Topley <ktopley@apple.com>
Update the swift support CMake rules from XCTest.  This adds support for
additional features like partial module compilation which improves
incremental builds.  It allows for executable and library builds.

Signed-off-by: Kim Topley <ktopley@apple.com>
Enhance add_wift_target to support building static libraries.  We would
always generate shared libraries previously.

Signed-off-by: Kim Topley <ktopley@apple.com>
This splits out the SDK overlay component and libdispatch runtime
itself.  Doing so enables the re-use of libdispatch with and without
swift and makes the behaviour similar across Darwin and other platforms.

Signed-off-by: Kim Topley <ktopley@apple.com>
Signed-off-by: Kim Topley <ktopley@apple.com>
Split Swift SDK Overlay

Signed-off-by: Kim Topley <ktopley@apple.com>
Remove the explicit /usr/include search path for the swift library build.  This
allows us to build for Windows as well.

Signed-off-by: Kim Topley <ktopley@apple.com>
build: remove "/usr/include" for swift
Signed-off-by: Kim Topley <ktopley@apple.com>
Treat windows like Linux and android and remove the BSD interfaces on
these targets.  This allows us to mostly build the SDK overlay for
Windows.

Signed-off-by: Kim Topley <ktopley@apple.com>
SDK: guard BSD specific paths against windows
Signed-off-by: Kim Topley <ktopley@apple.com>
Provide an alias for the import symbol as the ObjC runtime is normally
in a separate DLL and the compiler will annotate the function as being
DLLImport.  This allows us to resolve the symbols when building the SDK
overlay.

Signed-off-by: Kim Topley <ktopley@apple.com>
DispatchStubs: make more Windows friendly
Signed-off-by: Kim Topley <ktopley@apple.com>
MadCoder and others added 19 commits November 5, 2021 16:33
Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
Use an auto-reset event for the dispatch queue on Windows.  On Linux,
`eventfd` is used, which is auto-reset unless `EFD_SEMAPHORE` is
specified.  This mirrors that behaviour.  The test suite continues to
pass after this change.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
dispatch: use auto-reset event for dispatch queue
Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
The `DispatchIO` constructor maps to `dispatch_io_create`.  The value on
Windows for the `fd` (which is actually a `HANDLE`) is being truncated
since `dispatch_fd_t` is actually `Int` not `Int32` on Windows.  Use the
`dispatch_fd_t` to ensure that the right size is always passed along.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
IO: match the signature for `DispatchIO` with `dispatch_io_create`
Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
When compiling statically, we have to link against DispatchStubs in addition to the other dependencies, so we are defining a separate modulemap for that.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
Add modulemap for static compilation

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
_dispatch_runloop_queue_xref_dispose is declared in src/queue_internal.h
but the declaration is hidden behind DISPATCH_COCOA_COMPAT. This means
the call to _dispatch_runloop_queue_xref_dispose must also be put behind
this preprocessor symbol.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
Add missing DISPATCH_COCOA_COMPAT preprocessor symbol.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
These changes include:

  * hw_config.h: prevent referring to sysctlbyname on OpenBSD, as this
    is not available on all platforms.

  * transform.c: these stanzas referring to FreeBSD or Linux also apply
    to OpenBSD.

  * tests/dispatch_apply.c: stanza applying to Linux applies to OpenBSD
    and also tweak style for consistency.

  * tests/dispatch_io_net.c, tests/dispatch_test.h: stanzas applying to
    FreeBSD also apply to OpenBSD.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
Make some preliminary porting changes.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
There is a small typo in src/shims/lock.h.

Should read `transition` rather than `transiton`.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
docs: fix simple typo, transiton -> transition
Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
Android doesn't have a separate librt, it's just part of libc. Also, the static
build wasn't working for armv7-a, because the test executables wouldn't link
with the multiple definition errors listed in android/ndk#176, so use the
workaround given there.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
[android] Put in fixes for librt and armv7-a

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
The Windows 10 SDK Version 2104 (10.0.20348.0) which adds support for
Windows 11 introduces new enumerated values for the logical processor
configuration.  Only one of the two is documented at MSDN.

https://docs.microsoft.com/en-us/windows/win32/api/winnt/ne-winnt-logical_processor_relationship:
~~~
`RelationNumaNodeEx`

Introduced in TBD - Release Iron. Requests that the full affinity be
returned. Unlike the other relation types, `RelationNumaNodeEx` is not
used oninput. It is simply a request for `RelationNumaNode` with full
group information.
~~~

Treat this enumerated value as `RelationNodeNode`.  It is unclear what
the details of `RelationProcessorDie` is currently.  For now, we leave
that value ignored, though it is likely that we may have to address it
in the future once the value is explained.

Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
shims: adjust the Windows path for Windows 11
Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
Signed-off-by: Rokhini Prabhu <rokhinip@apple.com>
@rokhinip
Copy link
Contributor Author

rokhinip commented Nov 6, 2021

@swift-ci please test

@@ -40,6 +40,20 @@ int main(int argc, char *argv[]) {
if(DISPATCH_HAVE_EXTENDED_SLPI_20348)
add_compile_definitions(DISPATCH_HAVE_EXTENDED_SLPI_20348)
endif()

Copy link
Member

@das das Nov 6, 2021

Choose a reason for hiding this comment

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

not sure what's up with the github diff viewer but this difference isn't real, this file is identical between the two branches

#include <string.h>
#include <stdlib.h>

#include <mach/port.h>
Copy link
Contributor

Choose a reason for hiding this comment

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

Unprotected mach/port.h is a portability break. Availability.h appears to be missing, and os/base.h doesn't exist. os/object.h and os/clock.h does exist, but os/clock.h also refers to os/base.h, so something is missing here.

Copy link
Contributor

@3405691582 3405691582 Nov 9, 2021

Choose a reason for hiding this comment

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

Seems like os/base.h should switch on os/generic_*_base.h. os/generic_*_basae.h needs to also #define away SPI_UNAVAILABLE...

@3405691582
Copy link
Contributor

There's other Mach-specific stuff that needs to be untangled too that I haven't felt up to untangling right now, but that'll trip up on supported non-Mach platforms too...

Copy link
Collaborator

@compnerd compnerd left a comment

Choose a reason for hiding this comment

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

I'll try to run through a build of this in a the next day or two.

OS_SWIFT_NAME(swift_name) \
OS_OBJECT_SHOW_SUBCLASS(name, super, name, ## __VA_ARGS__)

#if defined(__LP64__)
Copy link
Collaborator

Choose a reason for hiding this comment

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

I think that this needs a || defined(_WIN64). Windows64 is not a LP64 but rather a LLP64.

@compnerd
Copy link
Collaborator

There is a lot of use of mach_port_t, but I don't yet understand the use of them here. I wonder if we need to provide equivalences for those APIs on Linux/Android/Windows.

@MadCoder
Copy link
Member

There is a lot of use of mach_port_t, but I don't yet understand the use of them here. I wonder if we need to provide equivalences for those APIs on Linux/Android/Windows.

the workgroup stuff is not relevant for non Darwin platforms and should be entirely hidden behind HAVE_MACH

@compnerd
Copy link
Collaborator

Thanks @MadCoder! That actually was very helpful. I do have a handful of patches to upload that improves stuff but is insufficient on its own. What would you prefer @rokhinip @MadCoder @das? I can push to the same branch, or create a separate branch that adds them. They aren't particularly freestanding, so I cannot just create PRs for main to address these items.

@das
Copy link
Member

das commented Nov 12, 2021

thanks @compnerd for looking at this!
It would be very useful to have a separate merge commit for the followup changes to this PR that we can cleanly split out, so I think a separate branch initially created off-of this one would be ideal so that we can either merge it to this branch or just merge the two to main one after the other (after a rebase)

@compnerd
Copy link
Collaborator

@das sounds good, I'm going to be pushing a series of changes to the same branch and have created a PR for ease of review. Expect a large number of changes, since I want to keep them tiny and targeted so we can deal with the individual issues. I've CC'ed the people here on #584.

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.