The Compilation and Building subsystem implements compilation and packaging by module, component, and product. A module is an target to build. It can be a dynamic library, static library, configuration file, or prebuilt module. A module must belong to a component and can belong to only one component. OpenHarmony uses customized GN templates to configure modules. For details about the GN basics, see https://gn.googlesource.com/gn/+/main/docs/reference.md.
The Compilation and Building subsystem implements compilation and packaging by module, component, and product. A module is a target to build. It can be a dynamic library, static library, configuration file, or prebuilt module. A module must belong to a component and can belong to only one component. OpenHarmony provides customized GN templates to configure modules. For details about the GN basics, see [GN Reference](https://gn.googlesource.com/gn/+/main/docs/reference.md).
The common templates for module configuration are as follows:
...
...
@@ -25,15 +25,15 @@ ohos_resources
# Other templates
# Configuration file
ohos_prebuild_etc
ohos_prebuilt_etc
# SA profile
ohos_sa_profile
```
You are recommended to use the OpenHarmony customized templates.
You are advised to use the OpenHarmony customized templates.
### C/C++ Template Example
### C/C++ Template Examples
The .gni file corresponding to the templates starting with **ohos** is located in **openharmony/build/templates/cxx/cxx.gni**.
>**NOTE**: Only **sources** and **part_name** are mandatory.
> **NOTE**<br>Only **sources** and **part_name** are mandatory.
## Adding and Building a Module
The figure below illustrates the process for adding a module. A module belongs to a component, which belongs to a subsystem. Please note that the chipset solution, as a special component, does not have a subsystem. You may need to:
The following figure shows the logic for adding a module. Generally, you need to add a module to a component of a subsystem. If there is no subsystem or component, you must add the subsystem and component first. Note that the chip solution is a special component and does not have a subsystem.
- Add a module to an existing component.
...
...
@@ -382,7 +409,7 @@ The figure below illustrates the process for adding a module. A module belongs t
@@ -64,18 +64,21 @@ The dependency between modules can be classified into **deps** (left in the figu
## Using Sanitizer
When adding a module, you can enable the Sanitizer, such as the integer overflow check and control-flow integrity (CFI), provided by the compiler as required. You can also enable the debug or release mode and configure a blocklist. Each configuration item is optional. It is**false** by default. You can also leave it empty.
When adding a module, you can enable the Sanitizer, such as the integer overflow check and control-flow integrity (CFI), provided by the compiler as required. You can also enable the debug or release mode and configure a blocklist. Each configuration item is optional and**false** by default. You can also leave it empty.
Sanitizer configuration example:
``` shell
ohos_shared_library("example"){
sanitize ={
cfi =true
cfi_cross_dso =true# CFI: shared library support.
integer_overflow =true
debug =true# Optional. The debug mode is disabled by default.
blocklist ="./blocklist.txt"# Optional. Enter the path of the blocklist.
cfi =true# Enable the CFI check.
cfi_cross_dso =true# Enable the cross-DSO CFI check.
integer_overflow =true# Enable the integer overflow check.
boundary_sanitize =true# Enable the bounds check.
ubsan =true# Enable some UBSAN options.
all_ubsan =true# Enable all UBSAN options.
debug =true# Enable the debug mode, which is disabled by default.
blocklist ="./blocklist.txt"# Path of the blocklist.
Currently, the following two types of Sanitizers are supported:
Currently, Sanitizers provides the following functions:
- Integer overflow check: provides check of unsigned integer overflow (unsigned_integer_overflow), check of signed integer overflow (signed_integer_overflow), or both (integer_overflow).
- CFI: prevents malware attacks from redirecting the control flow of a program.
-**integer_overflow**: provides check of unsigned integer overflow (unsigned_integer_overflow), check of signed integer overflow (signed_integer_overflow), or both (integer_overflow).
- CFI: provides CFI and cross-DSO CFI checks.
-**boundary_sanitize**: provides the bounds check.
-**ubsan**: checks some Undefined Behavior Sanitizer (UBSAN) options, including **bool**, **integer-divide-by-zero**, **return**, **returns-nonnull-attribute**, **shift-exponent**, **unreachable**, and **vla-bound**.
-**all_ubsan**: checks all UBSAN options.
**Release and Debug Modes**
...
...
@@ -96,6 +102,7 @@ Currently, the following two types of Sanitizers are supported:
- Release mode: If release mode is enabled, the application will be directly interrupted when an error occurs. This can protect the system against errors or maliciously attacks.
**Blocklist**
The blocklist specifies the functions or source programs that are not affected by Sanitizer in the module. It prevents benign behavior from being identified as errors or prevents hotspot functions from generating unreasonable and unacceptable overheads. Exercise caution when using this function.