search for: va_arg

# The future of the va_arg instruction ## Summary LLVM IR currently defines a va_arg instruction, which can be used to access a vararg. Few Clang targets make use of it, and it has a number of limitations. This RFC hopes to promote discussion on its future - how 'smart' should va_arg be? Should we be aiming to trans...

On 9 August 2017 at 19:38, Friedman, Eli <efriedma at codeaurora.org> wrote: > On 8/9/2017 9:11 AM, Alex Bradbury via llvm-dev wrote: >> >> Option 3: Teach va_arg to handle aggregates >> * In this option, va_arg might reasonably be expected to handle a >> struct, >> but would not be expected to have detailed ABI-specific knowledge. e.g. >> it >> won't automagically know whether a value of a certain size/type is >...

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009, it seems that Windows 64 bits is partially supported. So I tri...

Hi! I am trying to implement va_arg() on ppc32. Everything went smooth, except implementing va_arg() of 64bit int. Since i64 is not a legal type on ppc32 DAGTypeLegalizer::ExpandRes_VAARG() splits the va_arg(i64) into two i32 va_args. The problem with ppc32 va_arg is that it needs special "alignment" of its gpr pointer wh...

Hi folk, I'm writing a set of small C code to verify whether my pass handle some instruction correctly. One of the instruction I want to test is "va_arg", but compiling my variadic function does not generate any va_arg instruction. Is va_arg deprecated? Will va_arg instruction ever be generated by any front-end? The source code and llvm instructions are appended as follows. the c code #include<stdarg.h> #include<stdio.h> #include...

Hi everyone, I'm interested in variadic functions and how llvm handles them. I discovered that the Clang frontend is doing a great job at lowering the va_arg (precisely __builtin_va_arg) function into target dependent code. I have also seen the va_arg function that exist at IR level. I found some information about va_arg (IR one) that currently does not support all platform. But since 2009, it seems that Windows 64 bits is partially supported. So I tri...

To get clang to emit va_arg instructions for va_arg() calls, as opposed to manually lowering it in the frontend, same as the llvm-gcc patch sent earlier does. ~Will On Wed, Aug 17, 2011 at 2:41 PM, Eric Christopher <echristo at apple.com> wrote: > > On Aug 17, 2011, at 11:53 AM, Will Dietz wrote: > >> F...

I should have been more specific: "Why do we want this as an option? Do we want it on all the time? Why or why not?" -eric On Aug 17, 2011, at 3:02 PM, Will Dietz wrote: > To get clang to emit va_arg instructions for va_arg() calls, as > opposed to manually lowering it in the frontend, same as the llvm-gcc > patch sent earlier does. > > ~Will > > On Wed, Aug 17, 2011 at 2:41 PM, Eric Christopher <echristo at apple.com> wrote: >> >> On Aug 17, 2011, at 11:5...

Neal, FYI, my group has added a flag to llvm-gcc for emitting the va_arg instruction (instead of lowering in the front-end), and we also have an implementation of the VAARG instruction for X86-64. (which is currently not implemented in the LLVM backend). Both of these things will be sent upstream to LLVM soon, pending some more testing and review. If you are dire need...

Oh, sorry about that, and thanks for the clarification as to what you were looking for. Here you go: ** Why do we want this option? ** Presently clang will manually lower va_arg() in the frontend to the equivalent (relatively complicated!) IR, as opposed to making use of the LLVM va_arg instruction directly. IR that contains the va_arg instruction is much easier to analyze because it is concise and clear in its semantics. The lowered version IR is target-specific pointer...

Dear all, Is there a way to have llvm-gcc output the llvm va_arg intrinsic? As far as I understand, llvm-gcc directly lowers va_arg in the frontend using the TARGET_GIMPLIFY_VA_ARG target hook. I am aware that va_arg segfaults on x86-64 (http://llvm.org/bugs/show_bug.cgi?id=1740) and that llvm-gcc avoids this issue by always lowering calls to va_arg (http://old...

Hi all, I am currently writing an obfuscation pass (on LLVM 3.3 code base) that works at IR level and that implement procedures fusion. For this, I am heavily relying on the va_arg intrinsic. My code is functional when compiled with no optimization (-O0), but I experience strange behavior when compiling with -O2 or -O3. I am currently using the libgmp and OpenSSL libraries test suites. I know that clang is *not* relying on the va_arg intrinsic, but implements itself this se...

...on Sparc processors (specifically, LEON, but I suspect but can't verify that it also happens on all Sparc processors). The problem is, or appears to be with using double values in Sparc (32 bit). Specifically, double values are not being loaded into registers correctly within a function using va_args. Only half the value is loaded (i.e. 32, rather than 64 bits of the value). What I have also found is that the failure does not happen in all circumstances. The simplest situation I've been able to re-create that avoids the problem is to put a store and subsequent load instruction around the...

...case '6': case '7': case '8': case '9': if (pointflag) maxwidth = maxwidth * 10 + ch - '0'; else len = len * 10 + ch - '0'; goto nextch; case '*': if (pointflag) maxwidth = va_arg(args, int); else len = va_arg(args, int); goto nextch; case '.': pointflag = 1; goto nextch; case 'l': if (longflag) longlongflag = 1; else longflag = 1; goto nextch; case 'u': case 'U'...

I would like to be able to instrument va_arg, but when I generate a bc file for a test case using: llvm-gcc -O3 -emit-llvm vararg.c -c -o vararg.bc I do not see va_arg. Instead, it seems the args are accessed through %struct.__va_list_tag, which makes things a bit trickier to instrument. Is there a way to force llvm-gcc to use va_arg? Perh...

For the variadic function error with AMD64 abi and windows calling convention on 64bits x86, I find it has been tracked in Bug 20847 (https://llvm.org/bugs/show_bug.cgi?id=20847) (http://reviews.llvm.org/D1622#inline-9345). Do we still plan to fix it? You know, I meet exactly same va_arg mistake with llvm3.7 when I enable the Uefi firmware (http://www.uefi.org/) build with clang. The ms_abi is the Uefi firmware binary module standard interface. I really hope this bug fix can been checked in as soon as possible. If we cannot fix it in short time, could we offer a temporary fix patch...

...> --- docs/LangRef.rst | 44 ++++++++++++++++++++++++++++++-------------- 1 file changed, 30 insertions(+), 14 deletions(-) diff --git a/docs/LangRef.rst b/docs/LangRef.rst index ddef803..f429062 100644 --- a/docs/LangRef.rst +++ b/docs/LangRef.rst @@ -6695,7 +6695,8 @@ Overview: The '``va_arg``' instruction is used to access arguments passed through the "variable argument" area of a function call. It is used to implement -the ``va_arg`` macro in C. +the ``va_arg`` macro in C. Note that ``va_arg`` does not work on +platforms that have a non-builtin ``va_list`` type, like x...

hi,      I am porting llvm to our embedded cpu. By my abi, long long type is aligned by 8 bytes. But now llvm-gcc frontend follows x86 abi, generate word-alignment LLVM-IR for va_arg().    In some degree, llvm-gcc frontend depends on targets. The best solution is llvm-gcc can create va_arg node, I can lower it at the backend.    Who can give a temporary solution to make frontend can create 8 byte alignment code for long long type? Thanks     renkun. _____________...

FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg flag to Clang. Applies against mainline. (As discussed, va_arg isn't really supported well so this probably doesn't work well on anything other than simple code, YMMV, etc) ~Will On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > Have these changes made it to mainline? Is there a way to get a patch for the &g...

On Aug 17, 2011, at 11:53 AM, Will Dietz wrote: > FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg > flag to Clang. > > Applies against mainline. > > (As discussed, va_arg isn't really supported well so this probably > doesn't work well on anything other than simple code, YMMV, etc) > > ~Will > > On Thu, May 12, 2011 at 12:29 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: >> Have these changes made it to mainline? Is there a...