Skip to content

Fix CREATE_SYSV_VALIST issue - #372

Open
sunny868 wants to merge 1 commit into
lat-opensource:masterfrom
sunny868:tmp
Open

Fix CREATE_SYSV_VALIST issue#372
sunny868 wants to merge 1 commit into
lat-opensource:masterfrom
sunny868:tmp

Conversation

@sunny868

@sunny868 sunny868 commented Aug 4, 2026

Copy link
Copy Markdown
Contributor

Summary / 变更说明

直通libc中公共 printf 家族函数遇到变长参数转换错误,导致matlab测试失败。本patch做了修正。

Validation / 验证


//mini x64程序(main.c)即可复现
#include 
void test_vsprintf(const char *fmt, ...) {
    char buf[64];
    va_list ap;
    va_start(ap, fmt);
    vsprintf(buf, fmt, ap);   
    va_end(ap);
    puts(buf); // 预期输出hello.world 。 但开启wrappedlibc_private.h中GOWM(vsprintf, iFppA)后,输出乱码
}

int main() {
   test_vsprintf("%s.%s", "hello", "world"); 

@@ -76,7 +75,7 @@ typedef struct x64_va_list_s {
#endif

#define VARARGS sysv_varargs
#define PREPARE_VALIST CREATE_SYSV_VALIST(__MY_R_RSP)
#define PREPARE_VALIST CREATE_SYSV_VALIST(cpu->scratch)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

应该是传引用而不是上栈。

@sunny868

sunny868 commented Aug 7, 2026

Copy link
Copy Markdown
Contributor Author

从近期直通JVM的评估结果来看,类似这种的小修小补意义不大。只要是KZT开启,就存在libc内TLS数据割裂问题。以libc内线程局部数据locale为例:

同一个线程内运行x86和native函数:
//翻译执行的x86_64 main.c
uselocale("en_US.UTF-8"); //伪代码,调用x86_64的libc
//库直通的la64 libtest.so
uselocale(0); // 调用la64的libc, 预期输出 en_US.UTF-8, 实际为LC_GLOBAL_LOCALE

就是所谓“双架构地址空间”引起的数据不一致。根本解决估计还得是libc api 全直通+外挂TLS,实际上box64就是这么干的。

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

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant