similar to: [LLVMdev] Instrumenting all va_arg invocations

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

# 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 transition all targets and LLVM frontends to using it? ## Background on va_arg

Hi David, I'm working on source to source transformations and instrumentation. A flag to disable 'va_arg' lowering in LLVM FEs will be very useful. Have you sent your modifications upstream to LLVM? If not, could you please share link to your public repository. Thanks, Sergey Yakoushkin On Mon, Jul 19, 2010 at 11:18 PM, David Meyer <pdox at google.com> wrote: > Neal, >

Hi, we plan to remove -fsanitize-address-zero-base-shadow command line flag from clang, and disable zero-base shadow support on all platforms where it is not the default behavior. - It is completely unused, as far as we know. And completely undocumented, too. - It is ABI-incompatible with non-zero-base shadow, which means all objects in a process must be built with the same setting. Failing to

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 of these features now, I

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

Yes, it would be great to get that fixed. On Wed, Feb 5, 2014 at 4:09 PM, Evgeniy Stepanov <eugeni.stepanov at gmail.com>wrote: > On Thu, Feb 6, 2014 at 12:21 AM, Keno Fischer > <kfischer at college.harvard.edu> wrote: > > Looks like when you materialize the stores, you should check the size of > the > > the store and emit an appropriate amount of stores to the

Looks like when you materialize the stores, you should check the size of the the store and emit an appropriate amount of stores to the origin shadow (or just a memset intrinsic?). On Wed, Feb 5, 2014 at 2:13 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > The @entry stuff is just a gdb artifact. I've been tracking this back a > little further, and it seems there's

The code for ccall looks right. Sounds like you have a very small range of instructions where an uninitialized value appear. You could try debugging at asm level. Shadow for b should be passed at offset 0 in __msan_param_tls. MSan could propagate shadow through arithmetic and even some logic operations (like select). It could be that b is clean on function entry, but then something uninitialized

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

How is ccall() implemented? If it manually sets up a stack frame, then it also needs to store argument shadow values in paramtls. I don't think there is an overflow, unless you have a _lot_ of arguments in a function call. On Sun, Feb 2, 2014 at 9:26 AM, Keno Fischer <kfischer at college.harvard.edu> wrote: > Also, I was looking at the instrumented LLVM code and I noticed that the

On Fri, May 30, 2014 at 1:53 AM, Evgeniy Stepanov <eugeni.stepanov at gmail.com > wrote: > On Fri, May 30, 2014 at 12:41 AM, Alexey Samsonov <vonosmas at gmail.com> > wrote: > > Hi, > > > > I consider reducing the usage of blacklist in sanitizer instrumentation > > passes and doing the necessary work in frontend (Clang) instead. > > > > Some

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,

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

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

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: > >> FWIW, attached is a similar patch that adds a -falways-use-llvm-vaarg

I assume there are transitions between JITted code and native helper functions. How are you handling them? Are native functions MSan-instrumented? MSan is passing shadow across function calls in TLS slots. Does your TLS implementation guarantee that accesses to __msan_param_tls from JITted and from native code map to the same memory? On Mon, Jan 27, 2014 at 11:36 PM, Evgeniy Stepanov

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

I have verified that both TLS implementations indeed find the same area of memory. Anything else I could look for? On Tue, Jan 28, 2014 at 4:28 PM, Keno Fischer <kfischer at college.harvard.edu>wrote: > Yes, both JIT code and the native runtime are instrumented. I am under the > impressions that the the C library should guarantee that from the way the > relocations are

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,