|
| 1 | +# ABI Policy Guide |
| 2 | + |
| 3 | +## Intro |
| 4 | + |
| 5 | +Application Binary Interface is a contract between binary modules, that defines |
| 6 | +how structures and routines are accessed in machine code. Changing the ABI may |
| 7 | +break backwards compatibility of user application with the DPC++ runtime library |
| 8 | +for user-developed applications, resulting in need to rebuild such applications. |
| 9 | +The goal of this document is to provide guidelines for maintaining the current |
| 10 | +ABI of the DPC++ runtime library and mechanisms of notifying users about ABI |
| 11 | +changes. |
| 12 | + |
| 13 | +All ABI changes can be divided into two large groups: breaking and non-breaking. |
| 14 | +A breaking change means that the new binary is incompatible with the previous |
| 15 | +version (i.e. it can not be used as a drop-in replacement). A non-breaking |
| 16 | +change means that the forward compatibility is broken (i.e. the old library |
| 17 | +can be replaced with newer version, but not vice versa). |
| 18 | + |
| 19 | +The following non-exhaustive list contains changes that are considered to be |
| 20 | +breaking: |
| 21 | + |
| 22 | +1. Changing the size of exported symbol (for example, adding new member field |
| 23 | + to the exported class). |
| 24 | +1. Removing the exported symbol (that includes both changing the signature of |
| 25 | + exported routine and removing it). |
| 26 | +1. Changing the alignment of exported symbol. |
| 27 | +1. Changing the layout of exported symbol (for example, reordering class field |
| 28 | + members). |
| 29 | +1. Adding or removing base classes. |
| 30 | + |
| 31 | +Adding a new exported symbol is considered to be non-breaking change. |
| 32 | + |
| 33 | +## ABI Versioning Policy |
| 34 | + |
| 35 | +TBD |
| 36 | + |
| 37 | +## `__SYCL_EXPORT` Macro |
| 38 | + |
| 39 | +The `__SYCL_EXPORT` provides facilities for fine-grained control over exported |
| 40 | +symbols. Mark symbols that are supposed to be accessible by the user and that |
| 41 | +are implemented in the SYCL Runtime library with this macro. Template |
| 42 | +specializations also must be explicitly marked with `__SYCL_EXPORT` macro. |
| 43 | +Symbols not marked `__SYCL_EXPORT` have internal linkage. |
| 44 | + |
| 45 | +A few examples of when it is necessary to mark symbols with the macro: |
| 46 | + |
| 47 | +* The `device` class: |
| 48 | + - It is defined as API by the SYCL spec. |
| 49 | + - It is implemented in `device.cpp` file. |
| 50 | +* The `SYCLMemObjT` class: |
| 51 | + - It is not defined in the SYCL spec, but it is an implementation detail that |
| 52 | + is accessible by the user (buffer and image inherit from this class). |
| 53 | + - It has symbols that are implemented in the Runtime library. |
| 54 | + |
| 55 | +When it is not necessary to mark symbols with `__SYCL_EXPORT`: |
| 56 | +* The `buffer` class: |
| 57 | + - It is defined by the SYCL spec, but it is fully implemented in the headers. |
| 58 | +* The `ProgramManager` class: |
| 59 | + - It is an implementation detail. |
| 60 | + - It is not accessed from the header files that are available to users. |
| 61 | + |
| 62 | +## Automated ABI Changes Testing |
| 63 | + |
| 64 | +> The automated tests deal with the most commonly occurring problems, but they |
| 65 | +> may not catch some corner cases. If you believe your PR breaks ABI, but the |
| 66 | +> test does not indicate that, please, notify the reviewers. |
| 67 | +
|
| 68 | +There is a set of tests to help identifying ABI changes: |
| 69 | + |
| 70 | +* `test/abi/sycl_symbols_*.dump` contains dump of publicly available symbols. |
| 71 | + If you add a new symbol, it is considered non-breaking change. When the test |
| 72 | + reports missing symbols, it means you have either changed or remove some of |
| 73 | + existing API methods. In both cases you need to adjust the dump file. You |
| 74 | + can do it either manually, or by invoking the following command: |
| 75 | + ```shell |
| 76 | + python3 sycl/tools/abi_check.py --mode dump_symbols --output path/to/output.dump path/to/sycl.so(.dll) |
| 77 | + ``` |
| 78 | +* `test/abi/layout*` and `test/abi/symbol_size*` are a group of tests to check |
| 79 | + the internal layout of some classes. The layout tests check Clang AST for |
| 80 | + changes, while symbol_size check `sizeof` for objects. Changing the class |
| 81 | + layout is a breaking change. |
| 82 | + |
| 83 | +## Breaking ABI |
| 84 | + |
| 85 | +Whenever you need to change the existing ABI, please, follow these steps: |
| 86 | + |
| 87 | +1. Adjust you PR description to reflect (non-)breaking ABI changes. Make sure |
| 88 | + it is clear, why breaking ABI is necessary. |
| 89 | +2. Fix failing ABI tests in your Pull Request. Use aforementioned techniques to |
| 90 | + update test files. |
| 91 | +3. Update the library version according to the policies. |
0 commit comments