search for: __va_list_tag

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? Perhaps there is some documentation about va_list_tag or llvm's use of stdarg that would help me understand what is going on? Here is the C code... int sum(int n, ...) { int sum = 0; va_lis...

This code is generated for va_arg. %6 = getelementptr inbounds %struct.__va_list_tag* %5, i32 0, i32 3 ; <i8**> [#uses=1] %7 = load i8** %6, align 8 ; <i8*> [#uses=1] %8 = getelementptr inbounds [1 x %struct.__va_list_tag]* %ap, i64 0, i64 0 ; <%struct.__va_list_tag*> [#uses=1] %9 = getelementptr inbounds %struct.__va_list_tag* %8, i32 0,...

...t; count; i++) sum += va_arg(ap, int); va_end(ap); return sum; } I see LLVM that looks like it's been customized for the x86-64, versus the varargs stuff I was led to expect from the LLVM IR documentation. define i32 @add_em_up(i32 %count, ...) #0 { entry: %ap = alloca [1 x %struct.__va_list_tag], align 16 %arraydecay1 = bitcast [1 x %struct.__va_list_tag]* %ap to i8* call void @llvm.va_start(i8* %arraydecay1) %cmp7 = icmp sgt i32 %count, 0 br i1 %cmp7, label %for.body.lr.ph, label %for.end for.body.lr.ph: ; preds = %entry %gp_offset_p = getelem...

Hi, So the Variable Argument Handling Intrinsics section of the LangRef (http://llvm.org/docs/LangRef.html#variable-argument-handling-intrinsics) lists an example that segfaults. Try the following on x86_64: -- 8< -- define i32 @test(i32 %X, ...) { ; Initialize variable argument processing %ap = alloca i8* %ap2 = bitcast i8** %ap to i8* call void @llvm.va_start(i8* %ap2) ; Read a

...408 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *' | `-PointerType 0x8e423d0 'char *' | `-BuiltinType 0x8e41b40 'char' |-TypedefDecl 0x8e42728 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]' | `-ConstantArrayType 0x8e426d0 'struct __va_list_tag [1]' 1 | `-RecordType 0x8e424f0 'struct __va_list_tag' | `-CXXRecord 0x8e42458 '__va_list_tag' `-NamespaceDecl 0x8e42778 <example.hpp:5:1, line:7:1> line:5:11 ns `-VarDecl 0x8e8f970 <line:6:5, c...

On 4/4/2011 6:45 PM, Eli Friedman wrote: > On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal<arushi987 at gmail.com> wrote: >> >>> Hi, >>> Is it correct to convert, >>> %196 = load i32* %195, align 8 ;<i32> [#uses=1] >>> %197 = zext i32 %196 to i64 ;<i64> [#uses=1] >>> %198 =

...va_arg>` instruction and the -variable argument handling intrinsic functions are used. +This example shows how the variable argument handling is done on +x86_64. The complexity arises from the fact that ``va_arg`` does not +work on this type of ``va_list``. .. code-block:: llvm + %struct.__va_list_tag = type { i32, i32, i8*, i8* } + define i32 @test(i32 %X, ...) { ; Initialize variable argument processing - %ap = alloca i8* - %ap2 = bitcast i8** %ap to i8* + %ap = alloca %struct.__va_list_tag + %ap2 = bitcast %struct.__va_list_tag* %ap to i8* + %retptr = allo...

On Mon, 11 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > I am trying to build llvm-gcc4 on a amd64. I had to add the attached > patch to get the build system to select the correct library. Now the Applied. > build fails while compiling a code that has __builtin_va_copy. The > attached test.i fails with: > > cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* >

I am trying to build llvm-gcc4 on a amd64. I had to add the attached patch to get the build system to select the correct library. Now the build fails while compiling a code that has __builtin_va_copy. The attached test.i fails with: cc1: ../../trunk/gcc/llvm-convert.cpp:443: llvm::Value* TreeToLLVM::Emit(tree_node*, llvm::Value*): Assertion `(isAggregateType(((exp)->common.type)) == (DestLoc

On Mon, Apr 4, 2011 at 5:02 PM, Arushi Aggarwal <arushi987 at gmail.com> wrote: > > >> Hi, >> Is it correct to convert, >>   %196 = load i32* %195, align 8                  ; <i32> [#uses=1] >>   %197 = zext i32 %196 to i64                     ; <i64> [#uses=1] >>   %198 = ptrtoint i8* %193 to i64                 ; <i64> [#uses=1]

...000000107b180 in llvm::BumpPtrAllocator::Allocate(unsigned long, unsigned long) () (gdb) bt #0 0x000000000107b180 in llvm::BumpPtrAllocator::Allocate(unsigned long, unsigned long) () #1 0x00000000005ae35d in j3::JavaMethod::marshalArguments(vmkit::ThreadAllocator&, __va_list_tag*) () #2 0x00000000005b04e4 in j3::JavaObject* j3::JavaMethod::invokeStaticAP<j3::JavaObject*, j3::JavaObject* (*)(j3::JavaConstantPool*, void*, void*)>(j3::Jnjvm*, j3::Class*, __va_list_tag*) () #3 0x00000000005af054 in j3::JavaMethod::invokeJavaObjectStatic(j3::Jnjv...

...ng (and the NS variant) and are predefined to make these builtins behave correctly with modules. Adding them was intentional :-) > > To clarify, this is not so much about the appearance of new builtins > but that the structure has fields with no name. Other builtin > structures like __va_list_tag have names on their fields. FieldDecl > derives (indirectly) from NamedDecl. > > Our concern is that AST processing tools expect to find a name on > fields, and the changes in question introduced fields without names. > Can they be given names, if only for AST consistency? Yes, so...

...0000107b180 in llvm::BumpPtrAllocator::Allocate(unsigned long, > unsigned long) () > (gdb) bt > #0 0x000000000107b180 in llvm::BumpPtrAllocator::Allocate(unsigned long, > unsigned long) () > #1 0x00000000005ae35d in > j3::JavaMethod::marshalArguments(vmkit::ThreadAllocator&, __va_list_tag*) () > #2 0x00000000005b04e4 in j3::JavaObject* > j3::JavaMethod::invokeStaticAP<j3::JavaObject*, j3::JavaObject* > (*)(j3::JavaConstantPool*, void*, void*)>(j3::Jnjvm*, j3::Class*, > __va_list_tag*) () > #3 0x00000000005af054 in j3::JavaMethod::invokeJavaObjectStatic(j3::Jnj...

...16, at 7:16 AM, Brad King wrote: >> [snip] >>> __NSConstantString and __NSConstantString_tag are now exposed. >> To clarify, this is not so much about the appearance of new builtins >> but that the structure has fields with no name. Other builtin >> structures like __va_list_tag have names on their fields. FieldDecl >> derives (indirectly) from NamedDecl. >> >> Our concern is that AST processing tools expect to find a name on >> fields, and the changes in question introduced fields without names. >> Can they be given names, if only for AST co...

...00000393180ebe0 3 libc.so.6 0x0000003930830285 gsignal + 53 4 libc.so.6 0x0000003930831d30 abort + 272 5 vmjc 0x0000000000583cb7 ThrowNullPointerException + 71 6 vmjc 0x000000000050cf38 j3::JavaMethod::invokeIntSpecialAP(j3::Jnjvm*, j3::Class*, j3::JavaObject*, __va_list_tag*) + 56 7 vmjc 0x000000000050d715 j3::JavaMethod::invokeIntSpecial(j3::Jnjvm*, j3::Class*, j3::JavaObject*, ...) + 117 8 vmjc 0x0000000000524af8 j3::JavaObjectClass::getDeclaredConstructors(j3::JavaObjectClass*, bool) + 520 9 vmjc 0x0000000000530496 Java_java_lang...

...         unit size <integer_cst 0x20000820ba0 constant invariant 8>            align 64 offset_align 128            offset <integer_cst 0x20000820510 constant invariant 0>            bit offset <integer_cst 0x20000821530 constant invariant 0> context <record_type 0x200008440b0 __va_list_tag> chain <field_decl 0x200008460c0 __offset>>        pointer_to_this <pointer_type 0x20000b4c210>>    addressable used asm-frame-size 0 BLK file ../../source/gcc/libgcov.c line 818 size <integer_cst 0x20000820ea0 128> unit size <integer_cst 0x20000820ed0 16>    align...

...King wrote: >>> [snip] >>>> __NSConstantString and __NSConstantString_tag are now exposed. >>> To clarify, this is not so much about the appearance of new builtins >>> but that the structure has fields with no name. Other builtin >>> structures like __va_list_tag have names on their fields. FieldDecl >>> derives (indirectly) from NamedDecl. >>> >>> Our concern is that AST processing tools expect to find a name on >>> fields, and the changes in question introduced fields without names. >>> Can they be given name...

...t;invalid sloc> implicit __uint128_t 'unsigned __int128' |-TypedefDecl 0xd6c3c8 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *' `-TypedefDecl 0xd6c590 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]' ========================================================= LLVM IR ========================================================= target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-linux" !llvm.dbg.cu = !{!0} !llvm.module.flags = !{!327}...

...asprintf (strp=0x7f78ed249b38, fmt=0x7f78f0959c48 "server=%p client=%p message=%p prog=%p", list=0x7f78ed249c00) at util/virstring.c:334 334 util/virstring.c: No such file or directory. (gdb) p strp $7 = (char **) 0x7f78ed249b38 (gdb) p *strp $8 = 0x0 (gdb) p list $9 = (struct __va_list_tag *) 0x7f78ed249c00 (gdb) p *list $10 = {gp_offset = 48, fp_offset = 48, overflow_arg_area = 0x7f78ed249ce8, reg_save_area = 0x7f78ed249c20} ------------------------------------------------------------------------------------------------------------------------------------- ????????????????????????...

Andrew, That is not a clang issue. I think, in practice, {rcx, rdx, r8, r9} might not need to be spilled to "home area" in that case, because va_arg would not touch former 4 args. Lemme know if you had issues. I know it must be suboptimal, "home area" would be vacant in any cases afaik. It would be better to 4 args were spilled into the home area. To work on this, it might