Skip to content

Drop <stdint.h> dependency from <ptrauth.h> #7967

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

Conversation

DougGregor
Copy link
Member

This is needed to eliminate some cyclic module dependencies in some SDK configurations.

This is needed to eliminate some cyclic module dependencies in some
SDK configurations.
@DougGregor
Copy link
Member Author

@swift-ci please test

@ian-twilightcoder ian-twilightcoder self-requested a review January 12, 2024 01:05
@DougGregor DougGregor merged commit 002e3c1 into swiftlang:stable/20230725 Jan 12, 2024
@DougGregor DougGregor deleted the ptrauth-without-stdint branch January 12, 2024 07:07
@drodriguez
Copy link

The test in https://github.com/apple/llvm-project/blob/f981c3bcc4c7d9174545b2c7e7e67b27f235c741/clang/test/Sema/ptrauth-intrinsics-macro.c#L6 seemed to implicitly import stdint.h from ptrauth.h. For us it is failing, isn't it failing for you as well?

@DougGregor
Copy link
Member Author

Huh, did that test not get run by CI? We should replace the uintptr_t there with ptrauth_extra_data_t; I can put up a PR shortly.

@DougGregor
Copy link
Member Author

@drodriguez thank you!

@drodriguez
Copy link

Huh, did that test not get run by CI? We should replace the uintptr_t there with ptrauth_extra_data_t; I can put up a PR shortly.

Sadly the LLVM tests do not run by default, even if doing a "@-swift-ci please test" in this repository. One has to be explicit with "@-swift-ci please test llvm". I also think they are not green at the moment (https://ci.swift.org/view/Pull%20Requests/job/pr-apple-llvm-project-llvm-macos/, https://ci.swift.org/view/Pull%20Requests/job/pr-apple-llvm-project-llvm-linux/) so one has to drill down and check if none of the problems were actually introduced by the change itself.

I don't know if uintptr_t or ptrauth_extra_data_t is the right choice. It is actually the result of ptrauth_type_discriminator, which seems to be __UINTPTR_TYPE__.

ahmedbougacha added a commit that referenced this pull request Jun 11, 2024
This was originally fixed downstream as rdar://59828556, then in
stable/20230725 as #7967.  We ended up picking up the fixed version of
most of ptrauth.h (and the matching test) following the upstream commit
that added the file.  But the merge didn't remove the include;  it only
brought some of the `__UINTPTR_TYPE__` usage.

rdar://129378800
ahmedbougacha added a commit that referenced this pull request Jun 11, 2024
This was originally fixed downstream as rdar://59828556, then in
stable/20230725 as #7967.  We ended up picking up the fixed version of
most of ptrauth.h (and the matching test) following the upstream commit
that added the file.  But the merge didn't remove the include;  it only
brought some of the `__UINTPTR_TYPE__` usage.

rdar://129378800
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.

3 participants