search for: uninstru

Hi, I need to be able to use a special case list file containing thousands of entries (namely, a list of libc symbols, to be used when using DFSan with an uninstrumented libc). Initially I built the symbol list like this: fun:sym1=uninstrumented fun:sym2=uninstrumented fun:sym3=uninstrumented ... fun:sym6000=uninstrumented What I found was that, despite various bits of documentation [1,2], the symbol names are matched as substrings, the root cause being th...

...ideas? Attached is the fsanitize-blacklist I've used. Thanks, Tianyi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200403/2a8dfb54/attachment.html> -------------- next part -------------- fun:SSL*=uninstrumented fun:ssl*=uninstrumented fun:RAND*=uninstrumented fun:DES*=uninstrumented fun:ERR*=uninstrumented fun:MD5*=uninstrumented fun:MD4*=uninstrumented fun:*X509*=uninstrumented fun:OPENSSL*=uninstrumented fun:CRYPTO*=uninstrumented fun:TLS*=uninstrumented fun:BIO_*=uninstrumented fun:gzdopen=uninst...

Hi Peter! On Sat, Jul 13, 2013 at 4:38 AM, Peter Collingbourne <peter at pcc.me.uk>wrote: > Hi, > > I need to be able to use a special case list file containing thousands > of entries (namely, a list of libc symbols, to be used when using > DFSan with an uninstrumented libc). Initially I built the symbol > list like this: > > fun:sym1=uninstrumented > fun:sym2=uninstrumented > fun:sym3=uninstrumented > ... > fun:sym6000=uninstrumented > > What I found was that, despite various bits of documentation [1,2], > the symbol names ar...

...t; > > > > >> > > > > >>> But the code below that can also create wrapper functions which > do > > > not > > > > >>> need > > > > >>> debug info (lines 712-746). Wrappers normally show up for > > > uninstrumented > > > > >>> functions (e.g. main and many libc functions). > > > > >>> > > > > >>> > Could you provide any C/C++ source examples whis part of DFSan > > > fires > > > > >>> > reliably, so I could...

...;> >> Yep, that won't happen for free - we have to stitch it back into the >> debug info. >> >> >>> But the code below that can also create wrapper functions which do not >>> need >>> debug info (lines 712-746). Wrappers normally show up for uninstrumented >>> functions (e.g. main and many libc functions). >>> >>> > Could you provide any C/C++ source examples whis part of DFSan fires >>> > reliably, so I could experiment with some examples and see how the >>> debug >>> > info looks?...

...it back into the > > >> debug info. > > >> > > >> > > >>> But the code below that can also create wrapper functions which do > not > > >>> need > > >>> debug info (lines 712-746). Wrappers normally show up for > uninstrumented > > >>> functions (e.g. main and many libc functions). > > >>> > > >>> > Could you provide any C/C++ source examples whis part of DFSan > fires > > >>> > reliably, so I could experiment with some examples and see how the &gt...

...gt; so they should inherit the debug info for those functions. > Yep, that won't happen for free - we have to stitch it back into the debug info. > But the code below that can also create wrapper functions which do not need > debug info (lines 712-746). Wrappers normally show up for uninstrumented > functions (e.g. main and many libc functions). > > > Could you provide any C/C++ source examples whis part of DFSan fires > > reliably, so I could experiment with some examples and see how the debug > > info looks? > > This is an example of a program that exerc...

Hi Peter, After discovering several bugs in ArgumentPromotion and DeadArgumentElimination where llvm::Functions were replaced with similar functions (with the same name) to transform their type in some way, I started looking at all calls to llvm::Function::takeName to see if there were any other debug info quality bugs in similar callers. One such caller is the DataFlowSanitizer, and I don't

...his may work for simple standalone programs, > but you may run into puzzling failures. What type of failures do you mean? Does the symbol mismatch break assumptions in the ASan runtime? It's easy to imagine, for example, ASan missing use-after-free bugs because the call to free() is in an uninstrumented shared library. But would you expect stack-buffer-overflow and heap-buffer-overflow detection to work as expected? Thanks, Greg On Mon, Sep 23, 2013 at 1:42 AM, Evgeniy Stepanov <eugenis at google.com> wrote: > For the same reason we use shared runtime on OSX. > > We interc...

For the same reason we use shared runtime on OSX. We intercept libc calls by declaring a function with the same name in the sanitizer runtime library. Glibc loader puts main executable early in the symbol lookup order, which lets us interpose symbols from shared libraries with symbols from statically linked sanitizer runtime. Android (and AFAIK most other platforms) does not allow that, which is

...program with > SAFECode or Asan to find memory safety errors. When you run the program > under Valgrind, the portion of the code instrumented by SAFECode or Asan > runs natively without dynamic binary instrumentation because it's > already been instrumented. When the program calls uninstrumented code > (e.g., code in a dynamic library), Valgrind starts dynamic binary > instrumentation to do instrumentation. > > A really neat thing you could do with this is to share run-time data > structures between the LLVM and Valgrind instrumentation. For example, > Valgrind cou...

...linker to the plugin). If you're doing instrumentation, you might want to do what we did in SAFECode: perform instrumentation in the front-end and then use whole-program analysis to change/optimize the instrumentation in libLTO. That way, our libLTO transforms can always be turned on; for uninstrumented code, they become a no-op. -- John T. > *From: *John Criswell <criswell at illinois.edu > <mailto:criswell at illinois.edu>> > *Organization: *University of Illinois > *Date: *Tue, 12 Jul 2011 16:19:06 -0500 > *To: *Jinwook Shin <Jinwook.Shin at microsoft.com...

...threads drive n plugins, or if a thread pool of n threads drive m plugins. This would of course not work for globals, which naturally would be owned by the main thread. Also any kind of communication between plugins or back to the main thread would have to be mediated by the main thread or using uninstrumented/unsafe code. It's intended that the main code and plugin code are instrumented with different asan passes. >From what I have thought of yet (but I'd love feedback!), these changes are needed: 1. Storing+checking thread/plugin id in shadow byte. 2. Modified stack instrumentation...

...(uptr is unsigned long). Changing the data type of addresses passed to sanitizer runtime functions from uptr to void* will eliminate the need for the conversion to integer using ptrtoint. Removing the ptrtoint from asan instrumentation will boost the performance and will reduce the differences with uninstrumented code. 1. http://lists.llvm.org/pipermail/llvm-dev/2019-January/129095.html Many thanks, Reshabh and Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20200710/8d50223c/attachment.html>

In the example below, the Memory Sanitizier (from clang 3.3) reports an error: #include <math.h> int main() { double x; (void) modf(0, &x); if (x) { // Boom return 1; } return 0; } I see that modf() is not implemented by compiler-rt. Is it possible to make the Memory Sanitizer assume that all un-instrumented functions initialize any pointers arguments?

...ed to know if someone has a simple enough benchmark, that contains branches/calls/loops. Something mathematical would be fine. But as I said it should consist of more than one big function :-). I want to benchmark a dynamic instrumentation framework and need something to compare it against the uninstrumented software. It would be best if it was used somewhere else (so that it looks less homegrown). I haven't used much benchmarking code yet. So maybe anybody can point me at something. thanks in advance -- Jakob

Thanks John. Your approach worked fine for my small toy program. Now, I would like to run my module pass on a huge project (still a single executable) consisting of a few thousand bit code files scattered in many different directories. And some of them are static libraries. Do you still think it's a good idea to manually gather and link them with llvm-ld? I've seen other module pass

Hi, I decided to implement a sanitizer that tracks the active member, and reports reads from inactive members. e.g.: struct S { union { long l; char s[42]; double d; }; }; void f() { S s; s.d = 42.0; if (s.l > 100) // fire here ; } My current implementation is naïve (also possibly wrong), and doesn't care about "special

...of your instrumentation in bytes, you could generate inline assembly code that inserts the correct number of NOP instructions. Alternatively, if your processor has the necessary performance counter registers, you could simply measure the change in cache performance between the instrumented and uninstrumented code. For x86_64 processors, you can use VTune (which will sample the performance counter registers) or you can use the perfctr Linux kernel patch and tools to get a precise measurement. -- John T. > > Thanks > > > _______________________________________________ > LLVM...

On Wed, Dec 28, 2011 at 12:35 PM, Chandler Carruth <chandlerc at google.com>wrote: > On Wed, Dec 28, 2011 at 2:06 AM, Anton Korobeynikov < > anton at korobeynikov.info> wrote: > >> > I believe the best option for us is to add the >> > --fno-omit-frame-pointer depending on the -faddress-sanitizer flag. >> > But in order to do this reliably, we need