【openEuler22.03】SP2 ARM平台lazy binding策略下，从动态库调用sve函数时，第一次调用时sve寄存器值会被破坏，导致函数调用结果不正确

**【标题描述】能够简要描述问题：说明什么场景下，做了什么操作，出现什么问题（尽量使用正向表达方式）**
如下用例：
vim sve_test.c
#include <stdio.h>
#include "arm_sve.h"
extern svfloat32_t MySveFunc(svfloat32_t x)；// simple function from external dynamic library
int main()
{
    const float a[16] = {1.0f, 2.0f, 3.0f, 4.0f, 5.0f, 6.0f, 7.0f, 8.0f, 9.0f, 10.0f, 11.0f, 12.0f, 13.0f, 14.0f, 15.0f, 16.0f};
    float b[16];
    svfloat32_t x = svld1_f32_x(svptrue_b32(), a);
    svfloat32_t y = MySveFunc(x);
    svst1_f32_x(svptrue_b32(), b, y);
    for (int i = 0; i < 8; i++) {
        printf("b[%d]=%a\n", i, b[i]);
    }
    return 0;
}
使能lazy binding的方式动态编译用例
在sve256平台运行后，sve寄存器后半部分的结果计算错误。
**一、缺陷信息**

**内核信息：**

**缺陷归属组件：**

**缺陷归属的版本：**

**缺陷简述：**

**【环境信息】**
硬件信息
- 裸机场景请提供问题的硬件信息
- 虚拟机场景请提供虚拟机的XML文件或配置信息
软件信息
- OS版本及分支信息
- 内核信息
- 发现问题的组件版本信息
网络信息
- 如果有特殊组网，请提供网络拓扑信息

**【问题复现步骤】**，请描述具体的操作步骤
**【实际结果】**，请描述出问题的结果和影响
**【其他相关附件信息】**
比如系统message日志/组件日志、dump信息、图片等

**缺陷详情参考链接：**

**缺陷分析指导链接：**
原因分析：
查看汇编，在调用MySveFunc函数前，入参x全部保存在sve z0寄存器中，因为是lazy-binding的策略，第一次调用会跳转到ld-linux-aarch64.so库的dl_runtime_resolve函数去解析实际的地址，该函数内部会再次调用_dl_fix，并在调用前后保存和恢复了x0~x7, q0~q7寄存器，因为未对z寄存器进行保护，在恢复q0的时候，z0后半部分值丢失，导致最后函数计算不正确。
最新的glibc代码中，dl_runtime_resolve仍然只保存了x和q寄存器。对于这种sve函数调用场景必然会出错。
glibc-2.38\sysdeps\aarch64\dl-trampoline.S

src-openEuler/glibc
关闭

内容风险标识

评论 (3)

src-openEuler/glibc关闭 .gitee-modal { width: 500px !important; }

内容风险标识