llvm dev - Dec 2021 - Fwd: about clang compile c to wasm lost argument

---------- Forwarded message ---------
发件人： shankusu2017 <shankusu2017 at gmail.com>
Date: 2021年12月19日周日 18:17
Subject: Fwd: about clang compile c to wasm lost argument
To: <llvm-admin at lists.llvm.org>




---------- Forwarded message ---------
发件人： shankusu2017 <shankusu2017 at gmail.com>
Date: 2021年12月19日周日 18:15
Subject: about clang compile c to wasm lost argument
To: <surma at surma.dev>


hi:
   I use clang to compile the c code into wasm, and I found that clang13/14
regards the variable reference in the c language as a parameter, such as
the "..." part in int printf(const char *format, ...); In this way,
when I
implemented my own printf function in the host environment, wasm only
passed 2 parameters to the host when calling prinf, but I actually passed
more than 2 parameters. This will cause the printf function I implemented
by myself to receive only 2 parameters, and thus lose one parameter. The
attachment contains my original c code and compiled wasm and wat codes. The
green box part shows that the printf function only accepts 2 input
parameters. I don't know how to make clang understand that the number of
parameters received by printf is uncertain. Is there any solution?
   follow build cmd:
clang -I ../../src/ --target=wasm32 -nostdlib  -Wl,--no-entry
-Wl,--export-all -Wl,--allow-undefined --sysroot=/usr printf.c -o
../.././build/printf.wasm
wabt

wasm2wat printf.wasm -o printf.wat
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211219/0b840b3e/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: code.7z
Type: application/7z
Size: 109668 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211219/0b840b3e/attachment-0001.bin>

Hi,

The reason this happens is that Wasm functions can take a predefined 
number of parameters only, they cannot be truly variadic. Variadic 
functions are emulated by putting the extra arguments in memory and 
passing a pointer ("memory index" in wasm) to the first one instead of
`...` part of the argument list. That's why printf takes two arguments - 
first one is format string, the second is the pointer to the rest of the 
arguments.

Best,
Petr


On 12/19/21 02:48, shankusu2017 via llvm-dev wrote:
>
>
> ---------- Forwarded message ---------
> 发件人： *shankusu2017* <shankusu2017 at gmail.com>
> Date: 2021年12月19日周日 18:17
> Subject: Fwd: about clang compile c to wasm lost argument
> To: <llvm-admin at lists.llvm.org>
>
>
>
>
> ---------- Forwarded message ---------
> 发件人： *shankusu2017* <shankusu2017 at gmail.com>
> Date: 2021年12月19日周日 18:15
> Subject: about clang compile c to wasm lost argument
> To: <surma at surma.dev>
>
>
> hi:
>    I use clang to compile the c code into wasm, and I found that 
> clang13/14 regards the variable reference in the c language as a 
> parameter, such as the "..." part in int printf(const char
*format,
> ...); In this way, when I implemented my own printf function in the 
> host environment, wasm only passed 2 parameters to the host when 
> calling prinf, but I actually passed more than 2 parameters. This will 
> cause the printf function I implemented by myself to receive only 2 
> parameters, and thus lose one parameter. The attachment contains my 
> original c code and compiled wasm and wat codes. The green box part 
> shows that the printf function only accepts 2 input parameters. I 
> don't know how to make clang understand that the number of parameters 
> received by printf is uncertain. Is there any solution?
>    follow build cmd:
> clang -I ../../src/ --target=wasm32 -nostdlib  -Wl,--no-entry 
> -Wl,--export-all -Wl,--allow-undefined --sysroot=/usr printf.c -o 
> ../.././build/printf.wasm
> wabt
>
> wasm2wat printf.wasm -o printf.wat
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20211222/9b0d9f04/attachment.html>