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

Possible ABI changes in 4.0.2 #6949

Closed
opoplawski opened this issue Sep 1, 2019 · 5 comments
Closed

Possible ABI changes in 4.0.2 #6949

opoplawski opened this issue Sep 1, 2019 · 5 comments
Milestone

Comments

@opoplawski
Copy link
Contributor

Fedora's ABI checker is flagging some possibly incompatible changes in ABI from 4.0.1 to 4.0.2:

https://taskotron.fedoraproject.org/artifacts/all/0392d2bc-cc32-11e9-a7fd-52540077ca13/tests.yml/openmpi-4.0.2-0.2.rc1.fc31.log

ABI changes between build openmpi-4.0.2-0.2.rc1.fc31 and its latest stable build
================================================================================

This file contains possible ABI changes which have occurred due to this package update against latest stable build available in koji for the given Fedora release.

If you want to filter out these kind of ABI changes in the future, you can add a proper .abignore file to this package. To know more about how to write one, please look at the wiki page https://fedoraproject.org/wiki/Taskotron/Tasks/dist.abicheck#filtering .

On x86_64 architecture
*************************

* Incompatible ABI changes between:
openmpi-4.0.1-8.fc31.x86_64.rpm
openmpi-4.0.2-0.2.rc1.fc31.x86_64.rpm
ABI comparison took 8.03 second(s). Please review them.

================ changes of 'libmpi.so.40.20.1'===============
  Functions changes summary: 0 Removed, 0 Changed, 3 Added functions
  Variables changes summary: 3 Removed, 0 Changed (1 filtered out), 1 Added variables

  3 Added functions:

    'function int ompi_coll_base_retain_datatypes(ompi_request_t*, ompi_datatype_t*, ompi_datatype_t*)'    {ompi_coll_base_retain_datatypes}
    'function int ompi_coll_base_retain_datatypes_w(ompi_request_t*, ompi_datatype_t**, ompi_datatype_t**)'    {ompi_coll_base_retain_datatypes_w}
    'function int ompi_coll_base_retain_op(ompi_request_t*, ompi_op_t*, ompi_datatype_t*)'    {ompi_coll_base_retain_op}

  3 Removed variables:

    'ompi_communicator_t* comm'    {comm}
    'bool mpi_t_enabled'    {mpi_t_enabled}
    'int mpi_t_offset'    {mpi_t_offset}

  1 Added variable:

    'opal_class_t ompi_coll_base_nbc_request_t_class'    {ompi_coll_base_nbc_request_t_class}

================ end of changes of 'libmpi.so.40.20.1'===============

================ changes of 'liboshmem.so.40.21.0'===============
  Functions changes summary: 0 Removed, 5 Changed (10 filtered out), 4 Added functions
  Variables changes summary: 0 Removed, 3 Changed (4 filtered out), 1 Added variables

  4 Added functions:

    'function int mca_memheap_alloc_with_hint(size_t, long int, void**)'    {mca_memheap_alloc_with_hint}
    'function int mca_spml_base_put_all_nb(void*, void*, size_t, long int*)'    {mca_spml_base_put_all_nb}
    'function void* pshmemx_malloc_with_hint(size_t, long int)'    {shmemx_malloc_with_hint, aliases pshmemx_malloc_with_hint}
    'function void shmemx_alltoall_global_nb(void*, void*, size_t, long int*)'    {shmemx_alltoall_global_nb}

  5 functions with some indirect sub-type change:

    [C]'function int mca_memheap_base_alloc_init(mca_memheap_map_t*, size_t)' at memheap_base_alloc.c:22:1 has some indirect sub-type changes:
      parameter 3 of type 'long int' was added


    [C]'function sshmem_mkey_t* mca_memheap_base_get_cached_mkey_slow(map_segment_t*, int, void*, int, void**)' at memheap_base_mkey.c:679:1 has some indirect sub-type changes:
      parameter 1 of type 'map_segment_t*' changed:
        entity changed from 'map_segment_t*' to compatible type 'typedef shmem_ctx_t' at shmem.h:202:1
      parameter 2 of type 'int' changed:
        entity changed from 'int' to 'map_segment_t*'
        type size changed from 32 to 64 (in bits)
      parameter 3 of type 'void*' changed:
        entity changed from 'void*' to 'int'
        type size changed from 64 to 32 (in bits)
      parameter 4 of type 'int' changed:
        entity changed from 'int' to 'void*'
        type size changed from 32 to 64 (in bits)
      parameter 5 of type 'void**' changed:
        entity changed from 'void**' to 'int'
        type size changed from 64 to 32 (in bits)
      parameter 6 of type 'void**' was added


    [C]'function int mca_spml_base_oob_get_mkeys(int, uint32_t, sshmem_mkey_t*)' at spml_base.c:250:1 has some indirect sub-type changes:
      parameter 1 of type 'int' changed:
        entity changed from 'int' to 'typedef shmem_ctx_t' at shmem.h:202:1
        type size changed from 32 to 64 (in bits)
      parameter 2 of type 'typedef uint32_t' changed:
        entity changed from 'typedef uint32_t' to compatible type 'int'
          type name changed from 'unsigned int' to 'int'
          type size hasn't changed

      parameter 3 of type 'sshmem_mkey_t*' changed:
        entity changed from 'sshmem_mkey_t*' to 'typedef uint32_t' at stdint-uintn.h:26:1
        type size changed from 64 to 32 (in bits)
      parameter 4 of type 'sshmem_mkey_t*' was added


    [C]'function void mca_spml_base_rmkey_unpack(sshmem_mkey_t*, uint32_t, int, int)' at spml_base.c:255:1 has some indirect sub-type changes:
      parameter 1 of type 'sshmem_mkey_t*' changed:
        entity changed from 'sshmem_mkey_t*' to compatible type 'typedef shmem_ctx_t' at shmem.h:202:1
      parameter 2 of type 'typedef uint32_t' changed:
        entity changed from 'typedef uint32_t' to 'sshmem_mkey_t*'
        type size changed from 32 to 64 (in bits)
      parameter 3 of type 'int' changed:
        entity changed from 'int' to compatible type 'typedef uint32_t' at stdint-uintn.h:26:1
          type name changed from 'int' to 'unsigned int'
          type size hasn't changed

      parameter 5 of type 'int' was added


    [C]'function int mca_sshmem_segment_create(map_segment_t*, const char*, size_t)' at sshmem_base_wrappers.c:19:1 has some indirect sub-type changes:
      parameter 4 of type 'long int' was added



  1 Added variable:

    'mca_memheap_base_config_t mca_memheap_base_config'    {mca_memheap_base_config}

  3 Changed variables:

    [C]'mca_memheap_map_t mca_memheap_base_map' was changed at base.h:61:1:
      size of symbol changed from 264 to 648

    [C]'mca_spml_base_module_t mca_spml' was changed at spml.h:441:1:
      size of symbol changed from 192 to 200

    [C]'oob_comm memheap_oob' was changed at memheap_base_mkey.c:63:1:
      size of symbol changed from 66488 to 66496


================ end of changes of 'liboshmem.so.40.21.0'===============
@jsquyres jsquyres added this to the v4.0.2 milestone Sep 3, 2019
@jsquyres
Copy link
Member

jsquyres commented Sep 3, 2019

@opoplawski Many thanks for the report.

I think that all of these are ok. We only claim ABI on the official MPI and SHMEM API symbols, not the internet symbols. We probably don't hide as many of our internal symbols as we should, but that's a different issue.

@jsquyres
Copy link
Member

jsquyres commented Sep 3, 2019

Can others please review this report from @opoplawski and verify my analysis? Thanks.

@hppritcha
Copy link
Member

Except for the new OSHMEM entry points, the changes being detected are all for internal use and should not impact applications linked against previous releases of 4.0.x.

@opoplawski
Copy link
Contributor Author

Thanks for the confirmation

@gpaulsen
Copy link
Member

We discussed this a bit on today's webex: https://github.com/open-mpi/ompi/wiki/WeeklyTelcon_20190910.
Sounds like these changes are okay for v4.0.2, however we should discuss at our next face to face how we can define our position more clearly, and do a better job at being more deliberate about our ABI/API: (perhaps automate, perhaps generate white/black symbol lists for linking)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants