OpenHarmony（鸿蒙南向开发）——小型系统内核（LiteOS-A）【用户态内存调测】

最新推荐文章于 2024-09-23 15:07:25 发布
最新推荐文章于 2024-09-23 15:07:25 发布
阅读量1.2k 收藏 22
点赞数 27
分类专栏： OpenHarmony 鸿蒙开发 移动开发 文章标签： harmonyos OpenHarmony 鸿蒙内核 子系统 LiteOS-A 移动开发 鸿蒙开发
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/maniuT/article/details/140961610
版权
移动开发 同时被 3 个专栏收录
955 篇文章 13 订阅
订阅专栏
OpenHarmony
694 篇文章 18 订阅
订阅专栏
鸿蒙开发
504 篇文章 2 订阅
订阅专栏

基本概念

Debug版本的musl-libc库为用户提供内存泄漏检测、堆内存统计、踩内存分析以及backtrace功能等维测手段，可以提高用户态内存相关问题的定位效率。

采用了对malloc/free接口进行插桩，保存关键节点信息，然后程序在申请和释放内存时进行内存节点完整性校验，最后在程序结束时通过统计节点信息得到内存统计信息并根据统计信息判断内存是否泄漏的设计思想。

运行机制

内存泄漏检查

对于每个进程，内存调测模块维护了128个链表（当前系统的线程最大数量为128个），每个链表的索引为线程ID。

申请内存时：保存关键信息到内存节点控制块，根据当前线程ID将内存节点控制块挂到对应链表；

释放内存时：根据需要释放的内存地址匹配内存节点控制块并将该控制块删除。

图1 堆内存节点信息链表

申请内存时，返回地址会被保存到LR寄存器中。进程运行过程中，系统会在内存节点控制块中添加疑似泄漏点对应的lr等信息。如下图所示：

图2 堆内存节点信息

其中，TID表示线程ID；PID表示进程ID；ptr表示申请的内存地址；size表示申请的内存大小；lr[n]表示函数调用栈地址，变量n的大小可以根据具体场景的需要进行配置。

释放内存时，将free等接口的入参指针与node的ptr字段进行匹配，如果相同则删除该内存节点控制块信息。

用户通过串口或文件等方式，将各个进程内存调测信息导出，利用addr2line工具将导出的信息转换成导致内存泄漏的代码行，便可以解决内存泄露问题。

图3 泄漏点代码行定位流程

堆内存统计

用户态线程堆内存使用统计具有一定的实际意义，统计线程申请的堆内存占比，为用户程序的内存使用优化提供数据支持。用户态堆内存统计模块主要涉及的接口为malloc和free。如上图所示，每个进程维护128个链表，链表索引即线程ID，申请内存时系统将ptr和size信息记录在内存节点控制块中并将节点控制块挂在以线程ID为头信息的链表上，堆内存释放时根据ptr从对应的链表上移除相应的堆内存块信息；同时计算出当前线程所持有的堆内存总的使用量，并更新当前进程的堆内存使用量和堆内存使用峰值。

内存完整性检查

  • 使用malloc申请内存（小于等于0x1c000 bytes时通过堆分配算法分配） 用户程序申请堆内存时，在堆内存节点处添加校验值等信息，如果校验值异常，则很有可能是前一块堆内存使用越界导致的（目前无法识别校验值被野指针破坏的场景）。在内存申请、释放时校验内存节点校验值的正确性，若内存节点被破坏，校验失败时则输出tid、pid及当前被踩节点前一块堆内存申请时保存的调用栈信息，通过addr2line工具可获得具体的代码行信息，辅助用户解决问题。

图4 node节点头信息添加校验值

free堆内存时，不会立即把该内存块释放掉，而是在内存中写入魔术数字0xFE，并放到free队列中(保证在一定时间内不会再被malloc函数分配)，当有野指针或use-after-free的情况对该内存进行读取的操作时，能够发现数据异常，但是对于写操作则无法判断出来。

图5 free流程图

  • 使用malloc申请内存（大于0x1c000 bytes时通过mmap申请） 当malloc通过mmap申请大块内存时，在返回给用户使用的内存区间头和尾分别多申请一个页，一个页PAGE_SIZE当前为0x1000，这两个页分别通过mprotect接口设置权限为PROT_NONE（无可读可写权限），可以有效防止内存越界读写问题：越界读写数据时由于无读写权限而导致用户程序异常，根据异常调用栈信息可找到相应的代码逻辑。

图6 malloc通过mmap机制申请内存的内存布局

使用指导

接口说明

表1 内存调测功能

接口名描述
mem_check_init初始化内存检测模块。
watch_mem获取线程级堆内存使用信息。
check_leak检查是否有堆内存泄漏。
check_heap_integrity检查堆内存的完整性。
backtrace获取调用栈地址信息。
backtrace_symbols根据地址信息获取符号信息。
print_trace输出函数调用栈信息。

表2 调用栈回溯功能

接口名描述
backtrace获取调用栈地址信息。
backtrace_symbols根据地址信息获取符号信息。
print_trace输出函数调用栈信息。

使用说明

编译OpenHarmony工程时默认编译的是debug版本，即libc库已经集成内存调测相关的接口实现，用户可以根据具体需要决定是否使能内存调测功能。

堆内存调测功能提供两种方式供用户使用：接口调用及命令行参数。

  • 接口调用：优点是可以较精确的检查某一段代码逻辑的堆内存相关信息，缺点是需要修改用户代码。

  • 命令行参数：优点是无需修改用户代码，缺点是无法精确的校验某一段逻辑的堆内存信息。

说明： 内存调测功能使能后，进程退出时会默认进行一次堆内存泄漏和堆内存完整性检查。内存调测功能未使能时，堆内存统计、堆内存泄漏检查、堆内存完整性校验功能不会开启，调用相关调测接口无响应。

接口调用方式
示例代码

代码功能：显式调用调测模块的相关接口对用户代码进行内存校验。

#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>
#include <debug.h> // 包含提供内存调测接口声明的头文件

#define MALLOC_LEAK_SIZE  0x300

void func(void)
{
    char *ptr = malloc(MALLOC_LEAK_SIZE);
    memset(ptr, '3', MALLOC_LEAK_SIZE);
}

int main()
{
    mem_check_init(NULL); // 通过串口输出内存调测信息，必须在用户程序第一次申请堆内存之前调用（一般在main函数入口调用），否则调测信息不准确。
    // mem_check_init("/storage/mem_debug.txt"); // 内存调测信息输出到/storage/mem_debug.txt文件中，如果该文件创建失败，则信息通过串口输出。
    char *ptr = malloc(MALLOC_LEAK_SIZE);
    memset(ptr, '1', MALLOC_LEAK_SIZE);

    watch_mem(); // 在当前代码逻辑处查看线程级内存统计信息。
    func();
    check_heap_integrity(); // 检查堆内存节点完整性。
    check_leak(); // 在当前代码逻辑处检查堆内存是否泄漏（一般在程序退出之前校验比较准确，若在malloc和free调用逻辑之间做校验，则结果不准确）。
    return 0;
}
c
编译
$ clang -o mem_check mem_check.c -funwind-tables -rdynamic -g -mfloat-abi=softfp -mcpu=cortex-a7 -mfpu=neon-vfpv4 -target arm-liteos --sysroot=/home/<user-name>/directory/out/hispark_taurus/ipcamera_hispark_taurus/sysroot $(clang -mfloat-abi=softfp -mcpu=cortex-a7 -mfpu=neon-vfpv4 -target arm-liteos -print-file-name=libunwind.a)

说明：

  • 本编译示例基于将编译器的路径写入环境变量中，即.bashrc文件中。

  • 编译用户程序及所需的lib库时，需要添加编译选项-funwind-tables，-rdynamic，-g，用于栈回溯。

  • -mfloat-abi=softfp，-mcpu=cortex-a7，-mfpu=neon-vfpv4编译选项用于指定具体的芯片架构、浮点数计算优化、fpu，与具体的libc库使用的编译选项保持一致，否则链接时可能出现找不到libc库文件。

  • -target arm-liteos用于指定编译器相关库文件路径。

  • –sysroot=/home//directory/out/hispark_taurus/ipcamera_hispark_taurus/sysroot用于指定编译器库文件搜索根目录，假设OpenHarmony工程代码存放路径为/home//directory。其中out/hispark_taurus/ipcamera_hispark_taurus路径为在编译时，hb set命令指定的具体产品，本示例选择的是ipcamera_hispark_taurus产品。

  • $(clang -mfloat-abi=softfp -mcpu=cortex-a7 -mfpu=neon-vfpv4 -target arm-liteos -print-file-name=libunwind.a)用于指定相应的unwind库的路径。

调测信息
OHOS # ./mem_check
OHOS #
==PID:4== Heap memory statistics(bytes): // 堆内存统计信息
    [Check point]: // check点调用栈
        #00: <main+0x38>[0x86c] -> mem_check
        #01: <(null)+0x24baf9dc>[0x219dc] -> /lib/libc.so

    [TID: 18, Used: 0x320] // 18号线程堆内存占用，当前进程仅一个线程

==PID:4== Total heap: 0x320 byte(s), Peak: 0x320 byte(s)

Check heap integrity ok! // 堆内存完整性检查

==PID:4== Detected memory leak(s): // 内存泄漏信息及调用栈
    [Check point]:
        #00: <check_leak+0x1c4>[0x2da4c] -> /lib/libc.so
        #01: <main+0x44>[0x878] -> mem_check

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <main+0x1c>[0x850] -> mem_check
        #01: <(null)+0x24baf9dc>[0x219dc] -> /lib/libc.so

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <func+0x14>[0x810] -> mem_check
        #01: <main+0x3c>[0x870] -> mem_check
        #02: <(null)+0x24baf9dc>[0x219dc] -> /lib/libc.so

==PID:4== SUMMARY: 0x640 byte(s) leaked in 2 allocation(s).

==PID:4== Detected memory leak(s):
    [Check point]:
        #00: <check_leak+0x1c4>[0x2da4c] -> /lib/libc.so
        #01: <exit+0x28>[0x111ec] -> /lib/libc.so

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <main+0x1c>[0x850] -> mem_check
        #01: <(null)+0x24baf9dc>[0x219dc] -> /lib/libc.so

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <func+0x14>[0x810] -> mem_check
        #01: <main+0x3c>[0x870] -> mem_check
        #02: <(null)+0x24baf9dc>[0x219dc] -> /lib/libc.so

==PID:4== SUMMARY: 0x640 byte(s) leaked in 2 allocation(s).

Check heap integrity ok!
调用栈解析

提供parse_mem_info.sh脚本可以对调用栈进行解析，解析脚本存放的路径：kernel/liteos_a/tools/scripts/parse_memory/parse_mem_info.sh。利用脚本可以将相应的调测信息转换成具体的源码行号，如下命令所示，mem_debug.txt保存的是内存调测信息，elf1、elf2等文件是需要解析的elf文件。

$ ./parse_mem_info.sh mem_debug.txt elf1 elf2 elf3 ...

例如：

$ ./parse_mem_info.sh mem_debug.txt mem_check
Compiler is [gcc/llvm]: llvm
Now using addr2line ...

==PID:4== Heap memory statistics(bytes):
    [Check point]:
        #00: <main+0x38>[0x86c] at /usr1/xxx/TEST_ELF/mem_check.c:22
        #01: <(null)+0x24baf9dc>[0x219dc] -> /lib/libc.so

    [TID: 18, Used: 0x320]

==PID:4== Total heap: 0x320 byte(s), Peak: 0x320 byte(s)

Check heap integrity ok!

==PID:4== Detected memory leak(s):
    [Check point]:
        #00: <check_leak+0x1c4>[0x2da4c] -> /lib/libc.so
        #01: <main+0x44>[0x878] at /usr1/xxx/TEST_ELF/mem_check.c:28

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <main+0x1c>[0x850] at /usr1/xxx/TEST_ELF/mem_check.c:17
        #01: <(null)+0x24baf9dc>[0x219dc] -> /lib/libc.so

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <func+0x14>[0x810] at /usr1/xxx/TEST_ELF/mem_check.c:9
        #01: <main+0x3c>[0x870] at /usr1/xxx/TEST_ELF/mem_check.c:24
        #02: <(null)+0x24baf9dc>[0x219dc] -> /lib/libc.so

==PID:4== SUMMARY: 0x640 byte(s) leaked in 2 allocation(s).
命令行参数方式

对用户态进程进行内存相关的检查时，除了接口调用方式还可以通过命令行方式进行内存统计、内存泄漏或内存完整性检查。

--mwatch：初始化内存调测功能，注册信号。内存调测信息将从串口输出；
--mrecord <f_path>：初始化内存调测功能，注册信号。内存调测信息将保存至f_path文件，若f_path创建失败，则内存调测信息将从串口输出

在待调测的进程未退出时可使用信号机制获取对应信息:

kill -35 <pid> # 查看线程级堆内存占用
kill -36 <pid> # 检查是否存在堆内存泄漏
kill -37 <pid> # 检查堆内存头节点是否完整
示例代码

代码功能：构造内存问题利用命令行方式进行内存调测。

#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>

#define MALLOC_LEAK_SIZE  0x300

void func(void)
{
    char *ptr = malloc(MALLOC_LEAK_SIZE);
    memset(ptr, '3', MALLOC_LEAK_SIZE);
}

int main()
{
    char *ptr = malloc(MALLOC_LEAK_SIZE);
    memset(ptr, '1', MALLOC_LEAK_SIZE);
    func();
    while (1);
}
c
编译

参考接口调用章节里的编译。

使用mwatch参数命令
OHOS # ./mem_check --mwatch // 利用task命令可以查到mem_check进程的pid为4
OHOS #
OHOS # kill -35 4 // 查看堆内存统计信息
OHOS #
==PID:4== Heap memory statistics(bytes):
    [Check point]:
        #00: <arm_signal_process+0x5c>[0x58dfc] -> /lib/libc.so

    [TID: 18, Used: 0x640]

==PID:4== Total heap: 0x640 byte(s), Peak: 0x640 byte(s)

OHOS # kill -36 4 // 检查是否存在堆内存泄漏
OHOS #
==PID:4== Detected memory leak(s):
    [Check point]:
        #00: <check_leak+0x1c4>[0x2da4c] -> /lib/libc.so
        #01: <arm_signal_process+0x5c>[0x58dfc] -> /lib/libc.so

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <main+0x14>[0x724] -> mem_check
        #01: <(null)+0x2555a9dc>[0x219dc] -> /lib/libc.so

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <func+0x14>[0x6ec] -> mem_check
        #01: <main+0x30>[0x740] -> mem_check
        #02: <(null)+0x2555a9dc>[0x219dc] -> /lib/libc.so

==PID:4== SUMMARY: 0x640 byte(s) leaked in 2 allocation(s).

OHOS # kill -37 4 // 检查堆内存头节点的完整性
OHOS #
Check heap integrity ok!
调用栈解析

将调测信息保存至test.txt文件中，利用脚本进行解析，获取内存泄漏的具体行号。

$ ./parse_mem_info.sh test.txt mem_check
Compiler is [gcc/llvm]: llvm
Now using addr2line ...

==PID:4== Detected memory leak(s):
    [Check point]:
        #00: <check_leak+0x1c4>[0x2da4c] -> /lib/libc.so
        #01: <arm_signal_process+0x5c>[0x58dfc] -> /lib/libc.so

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <main+0x14>[0x724] at /usr1/xxx/TEST_ELF/mem_check.c:14
        #01: <(null)+0x2555a9dc>[0x219dc] -> /lib/libc.so

    [TID:18 Leak:0x320 byte(s)] Allocated from:
        #00: <func+0x14>[0x6ec] at /usr1/xxx/TEST_ELF/mem_check.c:8
        #01: <main+0x30>[0x740] at /usr1/xxx/TEST_ELF/mem_check.c:19
        #02: <(null)+0x2555a9dc>[0x219dc] -> /lib/libc.so

==PID:4== SUMMARY: 0x640 byte(s) leaked in 2 allocation(s).
使用mrecord参数命令
  1. 执行用户程序并指定记录内存调测信息的文件路径
    OHOS # ./mem_check --mrecord /storage/check.txt
  1. 利用kill -35 统计内存信息，该信息将会输出到文件中，使用cat命令查看
    OHOS # kill -35 4
    OHOS # Memory statistics information saved in /storage/pid(4)_check.txt

    OHOS # cat /storage/pid(4)_check.txt

    ==PID:4== Heap memory statistics(bytes):
        [Check point]:
            #00: <arm_signal_process+0x5c>[0x5973c] -> /lib/libc.so

        [TID: 18, Used: 0x640]

    ==PID:4== Total heap: 0x640 byte(s), Peak: 0x640 byte(s)
  1. 利用kill -36 校验内存完整性，该信息将会输出到文件中，使用cat命令查看
    OHOS # kill -36 4
    OHOS # Leak check information saved in /storage/pid(4)_check.txt

    OHOS # cat /storage/pid(4)_check.txt

    ==PID:4== Heap memory statistics(bytes):
        [Check point]:
            #00: <arm_signal_process+0x5c>[0x5973c] -> /lib/libc.so

        [TID: 18, Used: 0x640]

    ==PID:4== Total heap: 0x640 byte(s), Peak: 0x640 byte(s)

    ==PID:4== Detected memory leak(s):
        [Check point]:
            #00: <check_leak+0x1c4>[0x2e38c] -> /lib/libc.so
            #01: <arm_signal_process+0x5c>[0x5973c] -> /lib/libc.so

        [TID:18 Leak:0x320 byte(s)] Allocated from:
            #00: <main+0x14>[0x724] -> mem_check
            #01: <(null)+0x1fdd231c>[0x2231c] -> /lib/libc.so

        [TID:18 Leak:0x320 byte(s)] Allocated from:
            #00: <func+0x14>[0x6ec] -> mem_check
            #01: <main+0x30>[0x740] -> mem_check
            #02: <(null)+0x1fdd231c>[0x2231c] -> /lib/libc.so

    ==PID:4== SUMMARY: 0x640 byte(s) leaked in 2 allocation(s).
  1. 利用kill -9 杀掉当前进程，进程退出后会默认校验内存完整性，该信息将会输出到文件中，使用cat命令查看
    OHOS # kill -9 4
    OHOS # Leak check information saved in /storage/pid(4)_check.txt

    Check heap integrity ok!

    OHOS # cat /storage/pid(4)_check.txt
    OHOS #
    ==PID:4== Heap memory statistics(bytes):
        [Check point]:
            #00: <arm_signal_process+0x5c>[0x5973c] -> /lib/libc.so

        [TID: 18, Used: 0x640]

    ==PID:4== Total heap: 0x640 byte(s), Peak: 0x640 byte(s)

    ==PID:4== Detected memory leak(s):
        [Check point]:
            #00: <check_leak+0x1c4>[0x2e38c] -> /lib/libc.so
            #01: <arm_signal_process+0x5c>[0x5973c] -> /lib/libc.so

        [TID:18 Leak:0x320 byte(s)] Allocated from:
            #00: <main+0x14>[0x724] -> mem_check
            #01: <(null)+0x1fdd231c>[0x2231c] -> /lib/libc.so

        [TID:18 Leak:0x320 byte(s)] Allocated from:
            #00: <func+0x14>[0x6ec] -> mem_check
            #01: <main+0x30>[0x740] -> mem_check
            #02: <(null)+0x1fdd231c>[0x2231c] -> /lib/libc.so

    ==PID:4== SUMMARY: 0x640 byte(s) leaked in 2 allocation(s).

    ==PID:4== Detected memory leak(s):
        [Check point]:
            #00: <check_leak+0x1c4>[0x2e38c] -> /lib/libc.so
            #01: <exit+0x28>[0x11b2c] -> /lib/libc.so

        [TID:18 Leak:0x320 byte(s)] Allocated from:
            #00: <main+0x14>[0x724] -> mem_check
            #01: <(null)+0x1fdd231c>[0x2231c] -> /lib/libc.so

        [TID:18 Leak:0x320 byte(s)] Allocated from:
            #00: <func+0x14>[0x6ec] -> mem_check
            #01: <main+0x30>[0x740] -> mem_check
            #02: <(null)+0x1fdd231c>[0x2231c] -> /lib/libc.so

    ==PID:4== SUMMARY: 0x640 byte(s) leaked in 2 allocation(s).

说明： 上述连续记录的信息会逐步追加到初始化时所指定的文件中，故最后cat文件时，文件中还包含历史记录的信息内容。

常见问题

UAF(Use after free)

  • 申请小块内存（不大于0x1c000 bytes） free之后：

    读操作：读取free之后的内存大概率是魔术数字(0xFEFEFEFE)

说明： free之后的堆内存不会立即释放进堆内存池，会先放至固定长度的队列中，并置魔术数字0xFE，队列满后会将先放至队列中的内存块释放进堆内存池

写操作：无法校验。

  • 申请大块内存（大于0x1c000 bytes） 堆内存由malloc通过调用mmap接口申请，free之后若仍访问该内存，则用户程序异常（该内存区间已被unmap）。

Double free

Double free时，用户程序将会异常退出。

堆内存节点被踩

  • 申请小块内存（不大于0x1c000 bytes）

堆内存节点被踩时，用户程序将会异常退出，并输出破坏被踩节点的可能的堆内存申请调用栈，对于野指针踩内存情况无法校验出来。例如用户程序mem_check中存在堆内存越界踩的情况，利用命令行方式可以获得踩内存的可能的具体位置。

    OHOS # ./mem_check --mwatch
    OHOS #
    ==PID:6== Memory integrity information:
        [TID:28 allocated addr: 0x272e1ea0, size: 0x120] The possible attacker was allocated from:
            #00: <malloc+0x808>[0x640e8] -> /lib/libc.so
            #01: <threadFunc1+0x7c>[0x21d0] -> mem_check

可以通过调用栈解析脚本对调用栈信息进行解析。

  • 申请大块内存（大于0x1c000 bytes）

堆内存由malloc通过mmap接口申请，申请得到的堆内存块前后各置一个size为PAGE_SIZE大小的区间，设置无读写权限，读写操作会触发用户程序异常。

如果大家想更加深入的学习 OpenHarmony（鸿蒙南向） 开发的全栈内容，不妨可以参考以下相关学习文档进行学习，助你快速提升自己：

OpenHarmony 开发环境搭建：https://qr18.cn/CgxrRy

《OpenHarmony源码解析》：https://qr18.cn/CgxrRy

  • 搭建开发环境
  • Windows 开发环境的搭建
  • Ubuntu 开发环境搭建
  • Linux 与 Windows 之间的文件共享
  • ……

系统架构分析：https://qr18.cn/CgxrRy

  • 构建子系统
  • 启动流程
  • 子系统
  • 分布式任务调度子系统
  • 分布式通信子系统
  • 驱动子系统
  • ……

OpenHarmony 设备开发学习手册：https://qr18.cn/CgxrRy

在这里插入图片描述

OpenHarmony面试题（内含参考答案）：https://qr18.cn/CgxrRy

写在最后

  • 如果你觉得这篇内容对你还蛮有帮助，我想邀请你帮我三个小忙：
  • 点赞，转发，有你们的 『点赞和评论』，才是我创造的动力。
  • 关注小编，同时可以期待后续文章ing🚀，不定期分享原创知识。
  • 想要获取更多完整鸿蒙最新学习资源，请移步前往小编：https://qr21.cn/FV7h05

OpenHarmony_小贾
关注
专栏目录
鸿蒙小型系统内核Liteos-a开发指南
lcynone的博客
01-16 2468
轻量级物联网操作系统LiteOS-A开发指南__LCY
HarmonyOS内核liteos-a开发手册
09-17
鸿蒙对标的是Windows、安卓、IOS这类完整系统，Linux只是鸿蒙支持的内核之一。鸿蒙支持多种内核，有Linux，也有Liteos-a。Liteos-a为物联网而生，支持MMU，支持内核/APP空间隔离、支持各个APP空间隔离，系统更健壮；支持POSIX接口，大量开源软件可以在Liteos-a上直接使用；启动快，省电。
OpenHarmony（鸿蒙南向开发）——小型系统内核（LiteOS-A）【基本数据结构+标准库】
maniuT的博客
08-06 1131
双向链表是指含有往前和往后两个方向的链表，即每个结点中除存放下一个节点指针外，还增加一个指向前一个节点的指针。其头指针head是唯一确定的。从双向链表中的任意一个结点开始，都可以很方便地访问它的前驱结点和后继结点，这种数据结构形式使得双向链表在查找时更加方便，特别是大量数据的遍历。由于双向链表具有对称性，能方便地完成各种插入、删除等操作，但需要注意前后方向的操作。
OpenHarmony（鸿蒙南向开发）——小型系统内核（LiteOS-A）【LMS调测】
鸿蒙开发知识记录
09-23 1706
LMS全称为Lite Memory Sanitizer，是一种实时检测内存操作合法性的调测工具。LMS能够实时检测缓冲区溢出（buffer overflow），释放后使用（use after free) 和重复释放（double free), 在异常发生的第一时间通知操作系统，结合backtrace等定位手段，能准确定位到产生内存问题的代码行，极大提升内存问题定位效率。
OpenHarmonyOs / LiteOs-a 应用开发
mulongo的博客
04-29 2115
相关文章 前一篇：OpenHarmonyOs / LiteOs-a 驱动开发 文章目录相关文章前言一、瞎逼写点字总结 本文瞎逼介绍一下在 Ubuntu 20.04 系统进行 OpenHarmonyOs / LiteOs-a 应用开发。 开发板用的是润和的 ipcamera_hispark_taurus，芯片是 HI3516DV300。 前言 先挖个坑，以后再说，也可能不写了。 一、瞎逼写点字 瞎逼写点字 总结 下一篇讲讲系统移植？ ...
OpenHarmony（鸿蒙南向开发）——小型系统内核（LiteOS-A）【内存管理】
maniuT的博客
08-04 911
内存管理模块管理系统的内存资源，它是操作系统的核心模块之一，主要包括内存的初始化、分配以及释放。OpenHarmony LiteOS-A的堆内存管理提供内存初始化、分配、释放等功能。在系统运行过程中，堆内存管理模块通过对内存的申请/释放来管理用户和OS对内存的使用，使内存的利用率和使用效率达到最优，同时最大限度地解决系统的内存碎片问题。
OpenHarmony（鸿蒙南向开发）——小型系统内核（LiteOS-A）【扩展组件】中
maniuT的博客
08-05 759
OpenHarmony系统的动态加载与链接机制主要是由内核加载器以及动态链接器构成，内核加载器用于加载应用程序以及动态链接器，动态链接器用于加载应用程序所依赖的共享库，并对应用程序和共享库进行符号重定位。与静态链接相比，动态链接是将应用程序与动态库推迟到运行时再进行链接的一种机制。
鸿蒙OpenHarmony【小型系统编写“Hello World”程序】 （基于Hi3516开发板）
m0_62167422的博客
04-22 946
下方将展示如何在单板上运行第一个应用程序，其中包括新建应用程序、编译、烧写、运行等步骤，最终输出“Hello World！
鸿蒙内核Liteos-a开发手册.zip
03-30
《鸿蒙内核LiteOS-A开发手册》是一个深入解析华为鸿蒙操作系统内核 LiteOS-A 开发的参考资料，旨在帮助开发者理解和掌握如何在鸿蒙系统上进行轻量级操作系统的开发工作。LiteOS 是华为为物联网设备打造的一款轻量级...
HarmonyOS内核liteos-a开发手册.pdf
10-14
鸿蒙Liteos-a内核移植手册，很多人会混淆鸿蒙跟Linux的关系。 先举个例子，大家很熟悉的Windows里面含有内核，也含有UI系统，含有桌面程序，普通人可以直接使用Windows。 但是Linux仅仅是一个内核(它提供进程管理、...
基于鸿蒙内核LiteOS-A的源码精读与分析笔记
最新发布
09-29
该项目深入精读与分析基于鸿蒙内核LiteOS-A的源码，涵盖3035个文件，主要包括1341个C语言文件、906个C++文件、447个头文件等。内容涉及百万汉字注解分析，通过百篇博客进行深入解剖，全面挖掘内核地基工程。项目定期...
【起航】OpenHarmony远征04小型系统移植
Catdeo的博客
04-12 1076
openharmony小型系统内核移植 内核 支持的arch ROM 文件系统 Flash类型 Liteos-A ARMV7 >2M VFAT、JFFS2 SPI、NOR、NAND Linux-4.19 ARM、ARM64、MIPS、X86 >5M VFAT、JFFS2、EXT2 NOR、NAND、EMMC 编译构建系统介绍 编译框架与编译环境的搭建和之前的轻量系统移植类似 Liteos-A内核移植 Liteos-A支持ARM V7的指令集架构，若第三方芯片本身就是
浅谈OpenHarmony LiteOS-A内核之基础硬件——中断控制器GIC400
maniuT的博客
05-23 1135
OpenAtom OpenHarmony（以下简称“OpenHarmony”）采用多内核架构，支持Linux内核的标准系统、LiteOS-A的小型系统、LiteOS-M的轻量系统。其中LiteOS-A要求设备具备一定的处理能力，对比LiteOS-M，LiteOS-A支持以下特性：(1)MMU支持：通过MMU支持内核态和用户态分离，支持虚拟单元；(2)支持独立进程：调度对象分别为进程、线程；(3)支持文件系统：包括虚拟文件和块设备等；(4)支持更复杂的IPC：包括LiteIPC等；
openharmony中控屏开发：4.小型系统中控屏设计概述
产品经理铁牛
07-04 573
在我的产品开发诉求里，OpenHarmony带来最直接的价值在于：提供了轻量系统、小型系统、标准系统的整体解决方案，并支持应用程序一次开发多端部署。OpenHarmony标准系统，对应android系统，可用于更高硬件配置与性能需求的产品开发，后期分享的10寸中控屏设计方案，既采用标准系统实现。OpenHarmony小型系统，对应当前常见Linux版本的中控屏方案，主打性价比。接下来我大概会用10个章节的篇幅介绍一款4寸中控屏产品开发细节，包括结构、电路、系统、应用、语音交互几个部分。......
OpenHarmony（鸿蒙南向开发）——小型系统内核（LiteOS-A）【概述】
maniuT的博客
08-04 1078
OpenHarmony 轻量级内核是基于IoT领域轻量级物联网操作系统Huawei LiteOS内核演进发展的新一代内核，包含LiteOS-M和LiteOS-A两类内核。LiteOS-M内核主要应用于轻量系统，面向的MCU（Microprocessor Unit）一般是百K级内存，可支持MPU（Memory Protection Unit）隔离，业界类似的内核有FreeRTOS或ThreadX等；
OpenHarmony——LiteOS小故事（进程篇）
weixin_49591408的博客
07-11 695
本文内容为自己学习OpenHarmony中LiteOS的学习笔记及心得，因本人能力有限，内容或有错漏，请多包涵。本文会反复修正，持续更新。 小故事之奇葩打印机构（进程篇） 该小故事用来记录我的学习进度，会持续更新及更正。该小故事以LiteOS-a的运行为主线。...
[HarmonyOS][鸿蒙专栏开篇]快速入门OpenHarmony的LiteOS微内核
热门推荐
内核笔记
09-13 6万+
文章目录1、获取源码2、什么是LiteOS3、LiteOS的目录介绍4、LiteOS 中Make体系5、LiteOS 中Kconfig的配置5.1、顶层Kconfig5.2、具体板级的deconfig文件6、编译7、顶层目录下的config.mk文件主要完成如下功能的配置： 1、获取源码 OpenHarmony是HarmonyOS的开源版，由华为捐赠给开放原子开源基金会（OpenAtom Foundation）开源。第一个开源版本支持在128KB~128MB设备上运行，欢迎参加开源社区一起持续演进。 代码.
OpenHarmony学习 LiteOS研究篇（1） 新年新篇章
xian_gw的博客
01-02 445
我在学生时代，那时候嵌入式还是新名词，做东西普遍使用单片机，工程师个个从硬件到软件都能做，后来ARM7 Cortex A这些高性能处理器没两年就开始流行了，很多产品也开始上了系统，Linux、Android、WinCE等等，那个时候年轻，对技术有热情，顺着潮流学习了这些，没有被时代淘汰。但我还是想先从自己擅长的领域开始学，这样动力稍稍足一些，因此，我把目光放在了OpenHarmony系统，主要还是觉得华为的热度足够大，有点抱大腿的想法。想着每天学一些新的知识，安慰一下自己，用记录的方式来督促。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值