similar to: Asan code size overhead

On Wed, Oct 26, 2016 at 7:42 AM, Shi, Steven <steven.shi at intel.com> wrote: > Hi Kcc, > > I’m trying enabling the Asan in my firmware, but I find the asan > instrumentation code size impact is too big for me. I just implement > necessary firmware version runtime library functions (e.g. > __asan_report_load8) with blank body firstly to pass the asan enabled > build,

Specifically, the test is causing a link to occur for CGO stuff. It has been running 8 minutes now with Gold, and is producing a 400mb .o file afaict: % du -hs /tmp/go-build703430446/ llvm.org/llvm/bindings/go/llvm/_test/_obj_test/_cgo_.o 397M /tmp/go-build703430446/ llvm.org/llvm/bindings/go/llvm/_test/_obj_test/_cgo_.o What am I doing wrong here? -------------- next part -------------- An

On Fri, May 4, 2018 at 6:21 PM Kostya Serebryany <kcc at google.com> wrote: > On RAM... > You chose the 32-byte shadow granularity to reduce the RAM overhead, > but I am afraid this will actually increase it due to extra alignment requirements, > especially if an average allocation on your typical application is small. Good point. I will run our test suite with 8-byte shadow

On Mon, May 7, 2018 at 12:35 PM Walter Lee <waltl at google.com> wrote: > On Mon, May 7, 2018 at 2:05 PM Kostya Serebryany <kcc at google.com> wrote: > >> >> >>> and GetFakeStackFast. >> >> >> Not sure. Why don't just disable stack-use-after-return? >> > > Yeah originally I was going to do that, but: > I probably

On Fri, Nov 2, 2012 at 6:27 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote: > I just tried asan on an optimized 32 bit build of > ------------------------------------- > #include <stdint.h> > __attribute__((noinline)) > void f(uint64_t *p) { > *p = 42; > } > int main() { > void *p; > f((uint64_t*)&p); > } >

On Jan 6, 2013, at 10:54 AM, Kostya Serebryany wrote: > Alex (in CC) is working on asan for OS X. I think he can handle ubsan as well. > (but give us a few days, we are all out of office due to holidays). OK, thanks. If there are no objections, then I can go ahead and commit the attached test case fix I mentioned before. Adding ALWAYS_INLINE to 'free_common' in r158885 changed

Hi Meador, I couldn't reproduce the ASan failures on my 10.8 machine (trying that on a 10.7 one now) I'll look into making the in-process symbolizer work on OSX (which should fix some of the ubsan failures), but we do not need it in production currently, so I'm not sure when I get to it. On Mon, Jan 7, 2013 at 7:48 PM, Meador Inge <meadori at codesourcery.com> wrote: > >

On Wed, Feb 27, 2013 at 11:09 PM, Abdoulaye Walsimou Gaye <awg at embtoolkit.org> wrote: > This simple patch makes asan compile for mips (tested on mips32r2el). > The following test code: > int main() > { > char *x = (char*)malloc(10 * sizeof(char*)); > free(x); > return x[5]; > } It would help to enable compiler-rt tests on mips builders to

Hi, On Mon, May 13, 2013 at 10:49 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > A recent change added defined(__linux__) condition to the code below. > Now it says that on linux with --std=c++0x (or --std=c++11) the system > stdlib.h header must define aligned_alloc(). Really? > > include/__config: > > #if ( defined(__FreeBSD__) || defined(__linux__) )

On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > > On Mon, May 13, 2013 at 10:49 AM, Evgeniy Stepanov > <eugeni.stepanov at gmail.com> wrote: >> >> A recent change added defined(__linux__) condition to the code below. >> Now it says that on linux with --std=c++0x (or --std=c++11) the system >> stdlib.h header

Hi, On Mon, May 13, 2013 at 11:07 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > > I am guessing you are running on this on an old system. My glibc version > is > > 2.17 > > Yes. Ubuntu 12.04 LTS with glibc 2.15 does not have aligned_alloc. > Then I guess

You can use #if __GLIBC_PREREQ(2, 17) On Mon, May 13, 2013 at 1:13 PM, İsmail Dönmez <ismail at donmez.ws> wrote: > Hi, > > > On Mon, May 13, 2013 at 11:07 AM, Evgeniy Stepanov < > eugeni.stepanov at gmail.com> wrote: > >> On Mon, May 13, 2013 at 11:03 AM, İsmail Dönmez <ismail at donmez.ws> wrote: >> > I am guessing you are running on this on

On Mon, May 13, 2013 at 11:16 AM, Kostya Serebryany <kcc at google.com> wrote: > __GLIBC_PREREQ(2, 17) Attached patch should work. Please test. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130513/7670a30e/attachment.html> -------------- next part -------------- A non-text

Thanks, it works. 2.15 has quick_exit and at_quick_exit. The attached patch also works. On Mon, May 13, 2013 at 11:22 AM, İsmail Dönmez <ismail at donmez.ws> wrote: > > On Mon, May 13, 2013 at 11:16 AM, Kostya Serebryany <kcc at google.com> wrote: >> >> __GLIBC_PREREQ(2, 17) > > > Attached patch should work. Please test. > > Regards. >

Hi, On Mon, May 13, 2013 at 11:37 AM, Evgeniy Stepanov < eugeni.stepanov at gmail.com> wrote: > Thanks, it works. > 2.15 has quick_exit and at_quick_exit. The attached patch also works. > Looks good, please send it as a patch so it can be applied. Sorry for the breakage. Regards. -------------- next part -------------- An HTML attachment was scrubbed... URL:

On Fri, Jul 31, 2015 at 5:15 AM, Karl Skomski <karl at skomski.com> wrote: > Would it make sense to add the possibility to print a stacktrace also on > SIGFPE and not only on SIGSEGV or SIGBUS? > Yes, under a separate flag (handle_sigfpe=1). I think it's fine to have this flag on by default. Would you like to contribute a patch? > Only noticed that LibFuzzer doesn't

Fixed by LLVM r262063, thanks for reporting this! On Fri, Feb 26, 2016 at 11:35 AM, Alexey Samsonov <vonosmas at gmail.com> wrote: > Looking > > On Thu, Feb 25, 2016 at 9:13 PM, Kostya Serebryany <kcc at google.com> wrote: > >> +Alexey >> >> On Thu, Feb 25, 2016 at 5:30 AM, Diego Novillo <dnovillo at google.com> >> wrote: >>

> Basically, ASan is unable to map the necessary shadow memory. You may want > to dump the contents of /proc/self/maps and look if it conflicts > with the range ASan is trying to use. errno 12 is ENOMEM. Are you sure you > don't have constraints on the virtual memory your process can use? Similar thread in GCC ML: https://gcc.gnu.org/ml/gcc/2014-06/msg00023.html . It looks like

Hi, I'm trying to run the ASAN tests on ARM (to fix the CMake RT bot we have) and I'm hitting a different bug on my Chomebook than I have on the bots: [6/32] Generating ASAN_INST_TEST_OBJECTS.asan_interface_test.cc.arm-inline.o ... clang-3.6: warning: argument unused during compilation: '-march=armv7-a' clang (LLVM option parsing): Unknown command line argument

On 3 October 2014 14:42, Evgeniy Stepanov <eugenis at google.com> wrote: > this happens when x86 target is not compiled in. We really should (and > will) do something about it. > > Btw, you've asked the same question a month ago :) Sorry it has been > an issue for such a long time. No worries, I also haven't done much. But I need to get the RT bot green soon enough.