similar to: [HWASAN] Is Buildbot missing hwasan tests?

This commit has added __hwasan_memset to compiler-rt: commit 749bd83b08b7239f5d18c4e3095183919c68eb30 Author: Eugene Leviant <eleviant at accesssoftek.com> Date: Thu Dec 20 09:10:03 2018 +0000 [HWASAN] Add support for memory intrinsics This is patch complements D55117 implementing __hwasan_mem* functions in runtime Differential revision: https://reviews.llvm.org/D55554

Hi, On Fri, Sep 20, 2019 at 6:48 AM Matthew Malcomson <Matthew.Malcomson at arm.com> wrote: > > Hello again, > > I have been thinking more about the GCC implementation of hwasan and > found a few more questions that I would really appreciate help with. > > --- > I've noticed a match-all condition in the compiler inline > instrumentation, but can't see

Hello, I'm working on implementing hwasan instrumentation in GCC, and have just started discussing my current work-in-progress on the gcc-patches mailing list. (https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00387.html -- the email that Kostya saw and added people to). I've gotten about as basic a user-space implementation as possible (using the interceptor ABI) up and running, and would

Hello again, I had hoped that rc4 would be the last one, but I wanted to pick up one more fix, so here we go. Release Candidate 5 was just tagged as llvmorg-10.0.0-rc5 on the release branch at 35627038123. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc5 and https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc5 If nothing new comes up, I plan to tag

Thanks for prompt response, Andy This will work for cases when address is not modified. However this doesn’t seem to work for pre/post increment load stores. Consider data to address forwarding: $x0 = ldr x0, [x1] $x0, $x2 = ldr x2, [x0, 16]! The second instruction will have it’s own latency for address modification ($x0 register). So I don’t see how we can use ReadAdr stuff here. May be

Hi everyone, I believe the ABI for exception unwinding on a stack tagged with MTE needs to be clarified -- hopefully we can start the discussion here? (Please feel free to add people to the thread that you think would be interested). I'll outline some possible approaches that I think seem good below, I know Evgenii and Peter have done a lot of investigation in this area for HWASAN, so

On Wed, Jul 8, 2020 at 6:30 PM Kostya Serebryany <kcc at google.com> wrote: > > > On Wed, Jun 24, 2020 at 4:58 PM Teresa Johnson <tejohnson at google.com> > wrote: > >> Hi all, >> >> I've included an RFC for a heap profiler design I've been working on in >> conjunction with David Li. Please send any questions or feedback. For >>

Hi, Teresa, This looks really useful. It seems like this general infrastructure could be useful for diagnosing places where we have a lot of false sharing too. This could be between cores, sockets, or devices. Looking forward, especially with HMM and support under Linux for transparent unified memory between CPUs and accelerators, I anticipate we'll end up looking for places where some

On Sat, Jul 4, 2020 at 11:28 PM Wenlei He <wenlei at fb.com> wrote: > This sounds very useful. We’ve improved and used memoro > <https://www.youtube.com/watch?v=fm47XsATelI> for memory profiling and > analysis, and we are also looking for ways to leverage memory profile for > PGO/FDO. I think having a common profiling infrastructure for analysis > tooling as well as

Yep, it's once again variable and it's type using different scopes. Is there any strong reason why you set scope for global DIDerivedType? ________________________________________ От: Carlo Kok <ck at remobjects.com> Отправлено: 21 марта 2018 г. 18:22 Кому: Evgeny Leviant; llvm-dev at lists.llvm.org Тема: Re: [llvm-dev] lld/lto/win32 crash on DIE code Thanks! Unfortunately this

Hi all, I've included an RFC for a heap profiler design I've been working on in conjunction with David Li. Please send any questions or feedback. For sanitizer folks, one area of feedback is on refactoring some of the *ASAN shadow setup code (see the Shadow Memory section). Thanks, Teresa RFC: Sanitizer-based Heap Profiler Summary This document provides an overview of an LLVM

On Fri, May 4, 2018 at 7:09 PM Walter Lee <waltl at google.com> wrote: > 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

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. The pointers are 32-bit, right? Given how RAM-constrained your environment is, maybe you should consider something more like HWASAN instead of ASAN.

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

Thanks! Unfortunately this doesn't seem to cause it, because when I fix it to match the other files (and pretty much how clang emits it:) !0 = !DIGlobalVariableExpression(var: !1, expr: !DIExpression()) !1 = !DIGlobalVariable(name: "IDispatch_UID", linkageName: "f_t2b_RemObjects_d_Elements_d_System_d_____Global.IDispatchUID", scope: !2, file: !3, type: !622, isLocal:

Hi, I am trying to execute a simple hello world program compiled like so: path/to/compiled/clang -o test --target=aarch64-linux-gnu -march=armv8.5-a -fsanitize=hwaddress --sysroot=/usr/aarch64-linux-gnu/ -L/usr/lib/gcc/aarch64-linux-gnu/10.1.0/ -g test.c However, when I look at the disassembly, there is an unknown instruction listed at 0x2d51c: 000000000002d4c0 main: 2d4c0: ff c3 00 d1

Hi list, Is it possible to simulate load to store forwarding on aarch64 with MI scheduling model on AArch64? For instance $x0 data latency in the example below should be 1 cycle ldr $x0, [$x1] str $x0, [$x2] But it should be 4 cycles if we have another instruction: ldr $x0, [$x1] add $x0, $x0, 4 For ALU instructions it’s possible to use either ReadAdvance or SchedReadAdvance, but I don’t see

I ran our test suite with grain of 8 and 32, and more tests were able to avoid running out of memory with grain of 32 than 8. The ones that run out of memory on 8 but not 32 all failed trying to allocate a large region from the heap (350M). I haven't had any tests that run out of memory for other reasons. Given that, I will check in the current selected granularity of 32. I will try grain

Hello Carlo, I tried your reproducer and faced different problem from one you described (I'm using MacOS Sierra and lld built from trunk on Mar, 15). The crash happens when SelectionDAGBuilder::lowerInvokable tries to access EH info of this function: ms_t26_RemObjects_d_Elements_d_EUnit_d_Runnerb_RunChildrennt2a_RemObjects_d_Elements_d_EUnit_d_RunContext This happens because LLVM

I believe a good amount of them (if not most of them) have already been ported! Off the top of my head, I remember that asan, tsan, msan, hwasan, the kernel santizers, and sancov have been ported. I don't think ubsan has been ported yet though. You can also check if other passes you need run under the new PM by checking PassRegistry.def. On Fri, Aug 2, 2019, 14:20 Jordan Rupprecht