Skip to content

iOS (and other Apple platforms): the BCL has P/Invokes to libraries and/or functions that don't exist #47533

Closed
Closed
iOS (and other Apple platforms): the BCL has P/Invokes to libraries and/or functions that don't exist#47533
Assignees
MaximLipnin
Labels
area-Build-monoos-iosApple iOS

Description

@rolfbjarne
rolfbjarne
opened on Jan 27, 2021

Description

There are several DllImports in the BCL for iOS (and the other Apple platforms) that contain references to native functions that don't exist. It's highly preferable to not have any P/Invokes to native functions that don't exist, because it allows the AOT compiler to generate more efficient code. It also makes other performance improvements possible.

This is from the microsoft.netcore.app.runtime.ios-arm64 pack (6.0.0-alpha.1.21063.13).

Full output from custom tool I wrote: https://gist.github.com/rolfbjarne/b9a6f16d2a6697c0d8dfc46c39160404

Activity

  1. ghost added
    area-System.Security
    on Jan 27, 2021
  2. ghost added
    untriagedNew issue has not been triaged by the area owner
    on Jan 27, 2021
  4. bartonjs
    added
    area-Meta
    and removed
    area-System.Security
    on Jan 27, 2021

  5. bartonjs commented on Jan 27, 2021

    @bartonjs
    bartonjs
    on Jan 27, 2021
    Member
    System.Security.Cryptography.Algorithms.dll
    Library: libSystem.Security.Cryptography.Native.Apple.dylib Function: AppleCryptoNative_EccGenerateKey
        ❌ The function AppleCryptoNative_EccGenerateKey does not exist in libSystem.Security.Cryptography.Native.Apple.dylib

    Yeah, functions like that one are conditional:

    runtime/src/libraries/Native/Unix/System.Security.Cryptography.Native.Apple/pal_ecc.c

    Lines 6 to 9 in 1d9e50c

    #if !defined(TARGET_IOS) && !defined(TARGET_TVOS)
    int32_t AppleCryptoNative_EccGenerateKey(
    int32_t keySizeBits, SecKeychainRef tempKeychain, SecKeyRef* pPublicKey, SecKeyRef* pPrivateKey, int32_t* pOSStatus)
    {

    Just means that the relevant Interop.cs is being included in the iOS build when it doesn't need to.

  6. joperezr
    added
    os-iosApple iOS
    and removed
    untriagedNew issue has not been triaged by the area owner
    on Feb 9, 2021
  7. joperezr
    added this to the Future milestone on Feb 9, 2021
  8. marek-safar
    added
    area-Build-mono
    and removed
    area-Meta
    on Feb 18, 2021
  9. marek-safar
    modified the milestones: Future, 6.0.0 on Feb 18, 2021
  10. ghost added
    needs-further-triageIssue has been initially triaged, but needs deeper consideration or reconsideration
    on Feb 18, 2021
  11. marek-safar
    removed
    needs-further-triageIssue has been initially triaged, but needs deeper consideration or reconsideration
    on Feb 18, 2021

  12. 11 remaining items

  13. MaximLipnin commented on Jun 28, 2021

    @MaximLipnin
    MaximLipnin
    on Jun 28, 2021
    Contributor

    Regarding ReadFile pinvoke to kernel32.dll in System.Reflection.Metadata.dll - built for the apple mobile targets (e.g. using ./build.sh --arch x64 --os tvossimulator --configuration Release), this assembly doesn't contain any invocation of Interop.Kernel32.ReadFile

    image

  14. steveisok commented on Jun 28, 2021

    @steveisok
    steveisok
    on Jun 28, 2021
    Member

    @rolfbjarne do you have any info on where you were getting the Readfile pinvoke error from?

  15. filipnavara commented on Jun 29, 2021

    @filipnavara
    filipnavara
    on Jun 29, 2021
    Member

    System.Reflection.Metadata had a ReadFile call in one code path. I believe @adamsitnik removed it in one of the refactorings but it may still affect older NuGets.

  16. adamsitnik commented on Jun 29, 2021

    @adamsitnik
    adamsitnik
    on Jun 29, 2021
    Member

    System.Reflection.Metadata had a ReadFile call in one code path. I believe @adamsitnik removed it in one of the refactorings but it may still affect older NuGets.

    This is correct, I've removed it in #50367 for net6.0. We still have it for netstandard1.1 and netstandard2.0 where there is no Stream.Read(Span<byte>) which could be used instead

  17. rolfbjarne commented on Jun 29, 2021

    @rolfbjarne
    rolfbjarne
    on Jun 29, 2021
    MemberAuthor

    @rolfbjarne do you have any info on where you were getting the Readfile pinvoke error from?

    I ran my script again (on 6.0.0-preview.7.21324.1), and it only reports issues in System.Private.CoreLib.dll (full results).

    • There are numerous P/Invokes to GlobalizationNative_* functions in a libSystem.Globalization.Native.dylib, but there's no libSystem.Globalization.Native.dylib.
    • Two functions from libhostpolicy.dylib (corehost_resolve_component_dependencies and corehost_set_error_writer), but there's no libhostpolicy.dylib.

  18. filipnavara commented on Jun 29, 2021

    @filipnavara
    filipnavara
    on Jun 29, 2021
    Member

    There are numerous P/Invokes to GlobalizationNative_* functions in a libSystem.Globalization.Native.dylib, but there's no libSystem.Globalization.Native.dylib.

    That library is supposed to exist. Can you double check what is going on please? It may be a packaging issue.

    Two functions from libhostpolicy.dylib (corehost_resolve_component_dependencies and corehost_set_error_writer), but there's no libhostpolicy.dylib.

    Should be fixed by #54601.

  19. steveisok commented on Jun 29, 2021

    @steveisok
    steveisok
    on Jun 29, 2021
    Member

    There are numerous P/Invokes to GlobalizationNative_* functions in a libSystem.Globalization.Native.dylib, but there's no libSystem.Globalization.Native.dylib.

    That library is supposed to exist. Can you double check what is going on please? It may be a packaging issue.

    Yeah, that is strange.

    Are we going to need to do something about ReadFile for older versions?

  20. rolfbjarne commented on Jun 29, 2021

    @rolfbjarne
    rolfbjarne
    on Jun 29, 2021
    MemberAuthor

    Are we going to need to do something about ReadFile for older versions?

    Not for now at least, if it becomes a problem we can have a look at it later.

  21. akoeplinger commented on Jun 29, 2021

    @akoeplinger
    akoeplinger
    on Jun 29, 2021
    Member

    libSystem.Globalization.Native.dylib not existing is expected, the globalization PAL lib is statically linked into the runtime now since #44505.

    There's code in the runtime which hijacks the dllimport: https://github.com/dotnet/runtime/blob/main/src/mono/mono/metadata/native-library.c#L935-L941.

    On wasm we use NO_GLOBALIZATION_SHIM to skip that code but I'm wondering how it works there since that doesn't change the dllimport itself. edit: wasm is statically linking all libraries and uses https://github.com/dotnet/runtime/blob/57bfe474518ab5b7cfe6bf7424a79ce3af9d6657/src/tasks/WasmAppBuilder/PInvokeTableGenerator.cs to patch up the dllimports

  22. filipnavara commented on Jul 20, 2021

    @filipnavara
    filipnavara
    on Jul 20, 2021
    Member

    Is there anything left to be done for this issue?

  23. steveisok commented on Jul 20, 2021

    @steveisok
    steveisok
    on Jul 20, 2021
    Member

    I don't think so. @rolfbjarne ?

  24. rolfbjarne commented on Jul 20, 2021

    @rolfbjarne
    rolfbjarne
    on Jul 20, 2021
    MemberAuthor

    I don't think so either.

  25. steveisok
    closed this as completedon Jul 20, 2021
  26. steveisok
    removed this from the 6.0.0 milestone on Jul 22, 2021
  27. ghost locked as resolved and limited conversation to collaborators on Aug 21, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

area-Build-monoos-iosApple iOS

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions