en Copyright 2015 Java http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#42712698 Revert "[IR] `IRBuilderBase::CreateAdd()`: short-circuit `x + 0` --> `x`"Clang OpenMP codegen tests are failing.This reverts commit 288f1f8abe5835180a0021f142043ee261ab3846.This reverts commit cb90e5356ac1594e95fed8e208d6e0e9b6a87db1. List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Wed, 27 Oct 2021 19:19:10 +0000 Roman Lebedev <lebedev.ri@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#cb90e535 [IR] `IRBuilderBase::CreateAdd()`: short-circuit `x + 0` --> `x`There's precedent for that in `CreateOr()`/`CreateAnd()`.The motivation here is to avoid bloating the run-time check's IRin `SCEVExpander::generateOverflowCheck()`.Refs. https://reviews.llvm.org/D109368#3089809 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Wed, 27 Oct 2021 17:35:55 +0000 Roman Lebedev <lebedev.ri@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#86d1a0b3 [test] Remove some legacy PM tests in llvm/test/Instrumentation List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Sun, 05 Sep 2021 18:51:19 +0000 Arthur Eubanks <aeubanks@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#7b789562 [sanitizer] Place module_ctor/module_dtor in llvm.usedThis removes an abuse of ELF linker behaviors while keeping Mach-O/COFF linkerbehaviors unchanged.ELF: when module_ctor is in a comdat, this patch removes reliance on a linkerabuse (an SHT_INIT_ARRAY in a section group retains the whole group) by usingSHF_GNU_RETAIN. No linker behavior difference when module_ctor is not in a comdat.Mach-O: module_ctor gets `N_NO_DEAD_STRIP`. No linker behavior differencebecause module_ctor is already referenced by a `S_MOD_INIT_FUNC_POINTERS`section (GC root).PE/COFF: no-op. SanitizerCoverage already appends module_ctor to `llvm.used`.Other sanitizers: llvm.used for local linkage is not implemented in`TargetLoweringObjectFileCOFF::emitLinkerDirectives` (once implemented orswitched to a non-local linkage, COFF can use module_ctor in comdat (i.e.generalize ELF-specific rL301586)).There is no object file size difference.Reviewed By: vitalybukaDifferential Revision: https://reviews.llvm.org/D106246 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Wed, 21 Jul 2021 21:03:26 +0000 Fangrui Song <i@maskray.me> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#775a9483 [IR][sanitizer] Set nounwind on module ctor/dtor, additionally set uwtable if -fasynchronous-unwind-tablesOn ELF targets, if a function has uwtable or personality, or does not havenounwind (`needsUnwindTableEntry`), it marks that `.eh_frame` is needed in the module.Then, a function gets `.eh_frame` if `needsUnwindTableEntry` or `-g[123]` is specified.(i.e. If -g[123], every function gets `.eh_frame`.This behavior is strange but that is the status quo on GCC and Clang.)Let's take asan as an example. Other sanitizers are similar.`asan.module_[cd]tor` has no attribute. `needsUnwindTableEntry` returns true,so every function gets `.eh_frame` if `-g[123]` is specified.This is the root cause that`-fno-exceptions -fno-asynchronous-unwind-tables -g` produces .debug_framewhile`-fno-exceptions -fno-asynchronous-unwind-tables -g -fsanitize=address` produces .eh_frame.This patch* sets the nounwind attribute on sanitizer module ctor/dtor.* let Clang emit a module flag metadata "uwtable" for -fasynchronous-unwind-tables. If "uwtable" is set, sanitizer module ctor/dtor additionally get the uwtable attribute.The "uwtable" mechanism is generic: synthesized functions not cloned/specializedfrom existing ones should consider `Function::createWithDefaultAttr` instead of`Function::create` if they want to get some default attributes whichhave more of module semantics.Other candidates: "frame-pointer" (https://github.com/ClangBuiltLinux/linux/issues/955https://github.com/ClangBuiltLinux/linux/issues/1238), dso_local, etc.Differential Revision: https://reviews.llvm.org/D100251 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Wed, 21 Apr 2021 22:58:20 +0000 Fangrui Song <i@maskray.me> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#c042aff8 [NFC] Disallow unused prefixes under llvm/testThis patch sets the default for llvm tests, with the exception of testsunder Reduce, because quite a few of them use 'FileCheck' as parameterto a tool, and including a flag as that parameter would complicatematters.The rest of the patch undo-es the lit.local.cfg changes we progressivelyintroduced as temporary measure to avoid regressions under variousdirectories.Differential Revision: https://reviews.llvm.org/D95111 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Thu, 21 Jan 2021 02:37:22 +0000 Mircea Trofin <mtrofin@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#0930763b hwasan: Move fixed shadow behind opaque no-op cast as well.This is a workaround for poor heuristics in the backend where we canend up materializing the constant multiple times. This is particularlybad when using outlined checks because we materialize it for every call(because the backend considers it trivial to materialize).As a result the field containing the shadow base value will alwaysbe set so simplify the code taking that into account.Differential Revision: https://reviews.llvm.org/D90425 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Tue, 27 Oct 2020 23:26:07 +0000 Peter Collingbourne <peter@pcc.me.uk> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#c336557f hwasan: Compatibility fixes for short granules.We can't use short granules with stack instrumentation when targeting olderAPI levels because the rest of the system won't understand the short granuletags stored in shadow memory.Moreover, we need to be able to let old binaries (which won't understandshort granule tags) run on a new system that supports short granuletags. Such binaries will call the __hwasan_tag_mismatch function when theiroutlined checks fail. We can compensate for the binary's lack of supportfor short granules by implementing the short granule part of the check inthe __hwasan_tag_mismatch function. Unfortunately we can't do anything aboutinline checks, but I don't believe that we can generate these by default onaarch64, nor did we do so when the ABI was fixed.A new function, __hwasan_tag_mismatch_v2, is introduced that lets codetargeting the new runtime avoid redoing the short granule check. Because tagmismatches are rare this isn't important from a performance perspective; themain benefit is that it introduces a symbol dependency that prevents binariestargeting the new runtime from running on older (i.e. incompatible) runtimes.Differential Revision: https://reviews.llvm.org/D68059llvm-svn: 373035 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Fri, 27 Sep 2019 01:02:10 +0000 Peter Collingbourne <peter@pcc.me.uk> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#3b82b92c hwasan: Initialize the pass only once.This will let us instrument globals during initialization. This requiredmaking the new PM pass a module pass, which should still provide access toanalyses via the ModuleAnalysisManager.Differential Revision: https://reviews.llvm.org/D64843llvm-svn: 366379 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Wed, 17 Jul 2019 21:45:19 +0000 Peter Collingbourne <peter@pcc.me.uk> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#1366262b hwasan: Improve precision of checks using short granule tags.A short granule is a granule of size between 1 and `TG-1` bytes. The sizeof a short granule is stored at the location in shadow memory where thegranule's tag is normally stored, while the granule's actual tag is storedin the last byte of the granule. This means that in order to verify that apointer tag matches a memory tag, HWASAN must check for two possibilities:* the pointer tag is equal to the memory tag in shadow memory, or* the shadow memory tag is actually a short granule size, the value being loaded is in bounds of the granule and the pointer tag is equal to the last byte of the granule.Pointer tags between 1 to `TG-1` are possible and are as likely as any othertag. This means that these tags in memory have two interpretations: the fulltag interpretation (where the pointer tag is between 1 and `TG-1` and thelast byte of the granule is ordinary data) and the short tag interpretation(where the pointer tag is stored in the granule).When HWASAN detects an error near a memory tag between 1 and `TG-1`, itwill show both the memory tag and the last byte of the granule. Currently,it is up to the user to disambiguate the two possibilities.Because this functionality obsoletes the right aligned heap feature ofthe HWASAN memory allocator (and because we can no longer easily testit), the feature is removed.Also update the documentation to cover both short granule tags andoutlined checks.Differential Revision: https://reviews.llvm.org/D63908llvm-svn: 365551 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Tue, 09 Jul 2019 20:22:36 +0000 Peter Collingbourne <peter@pcc.me.uk> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#7108df96 hwasan: Remove the old frame descriptor mechanism.Differential Revision: https://reviews.llvm.org/D63470llvm-svn: 364665 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Fri, 28 Jun 2019 17:53:26 +0000 Peter Collingbourne <peter@pcc.me.uk> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#0cdd3b1d [NewPM] Port HWASan and Kernel HWASanPort hardware assisted address sanitizer to new PM following the same guidelines as msan and tsan.Changes:- Separate HWAddressSanitizer into a pass class and a sanitizer class.- Create new PM wrapper pass for the sanitizer class.- Use the getOrINsert pattern for some module level initialization declarations.- Also enable kernel-kwasan in new PM- Update llvm tests and add clang test.Differential Revision: https://reviews.llvm.org/D61709llvm-svn: 360707 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Tue, 14 May 2019 21:17:21 +0000 Leonard Chan <leonardchan@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#73078ecd hwasan: Move memory access checks into small outlined functions on aarch64.Each hwasan check requires emitting a small piece of code like this:https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html#memory-accessesThe problem with this is that these code blocks typically bloat codesize significantly.An obvious solution is to outline these blocks of code. In fact, thishas already been implemented under the -hwasan-instrument-with-callsflag. However, as currently implemented this has a number of problems:- The functions use the same calling convention as regular C functions. This means that the backend must spill all temporary registers as required by the platform's C calling convention, even though the check only needs two registers on the hot path.- The functions take the address to be checked in a fixed register, which increases register pressure.Both of these factors can diminish the code size effect and increasethe performance hit of -hwasan-instrument-with-calls.The solution that this patch implements is to involve the aarch64backend in outlining the checks. An intrinsic and pseudo-instructionare created to represent a hwasan check. The pseudo-instructionis register allocated like any other instruction, and we allow theregister allocator to select almost any register for the address tocheck. A particular combination of (register selection, type of check)triggers the creation in the backend of a function to handle the checkfor specifically that pair. The resulting functions are deduplicated bythe linker. The pseudo-instruction (really the function) is specifiedto preserve all registers except for the registers that the AAPCSspecifies may be clobbered by a call.To measure the code size and performance effect of this change, Itook a number of measurements using Chromium for Android on aarch64,comparing a browser with inlined checks (the baseline) against abrowser with outlined checks.Code size: Size of .text decreases from 243897420 to 171619972 bytes,or a 30% decrease.Performance: Using Chromium's blink_perf.layout microbenchmarks Imeasured a median performance regression of 6.24%.The fact that a perf/size tradeoff is evident here suggests thatwe might want to make the new behaviour conditional on -Os/-Oz.But for now I've enabled it unconditionally, my reasoning being thathwasan users typically expect a relatively large perf hit, and ~6%isn't really adding much. We may want to revisit this decision inthe future, though.I also tried experimenting with varying the number of registersselectable by the hwasan check pseudo-instruction (which would resultin fewer variants being created), on the hypothesis that creatingfewer variants of the function would expose another perf/size tradeoffby reducing icache pressure from the check functions at the cost ofregister pressure. Although I did observe a code size increase withfewer registers, I did not observe a strong correlation between thenumber of registers and the performance of the resulting browser on themicrobenchmarks, so I conclude that we might as well use ~all registersto get the maximum code size improvement. My results are below:Regs | .text size | Perf hit-----+------------+---------~all | 171619972 | 6.24% 16 | 171765192 | 7.03% 8 | 172917788 | 5.82% 4 | 177054016 | 6.89%Differential Revision: https://reviews.llvm.org/D56954llvm-svn: 351920 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Wed, 23 Jan 2019 02:20:10 +0000 Peter Collingbourne <peter@pcc.me.uk> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#d3a3e4b4 hwasan: Move ctor into a comdat.Differential Revision: https://reviews.llvm.org/D55733llvm-svn: 349413 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Mon, 17 Dec 2018 22:56:34 +0000 Peter Collingbourne <peter@pcc.me.uk> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#af95597c [hwasan] add stack frame descriptions.Summary:At compile-time, create an array of {PC,HumanReadableStackFrameDescription}for every function that has an instrumented frame, and pass this arrayto the run-time at the module-init time.Similar to how we handle pc-table in SanitizerCoverage.The run-time is dummy, will add the actual logic in later commits.Reviewers: morehouse, eugenisReviewed By: eugenisSubscribers: srhines, llvm-commits, kubamracekDifferential Revision: https://reviews.llvm.org/D53227llvm-svn: 344985 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Tue, 23 Oct 2018 00:50:40 +0000 Kostya Serebryany <kcc@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#090f0f95 [hwasan] Record and display stack history in stack-based reports.Summary:Display a list of recent stack frames (not a stack trace!) whentag-mismatch is detected on a stack address.The implementation uses alignment tricks to get both the address ofthe history buffer, and the base address of the shadow with a single8-byte load. See the comment in hwasan_thread_list.h for moredetails.Developed in collaboration with Kostya Serebryany.Reviewers: kccSubscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commitsDifferential Revision: https://reviews.llvm.org/D52249llvm-svn: 342923 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Mon, 24 Sep 2018 23:03:34 +0000 Evgeniy Stepanov <eugeni.stepanov@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#20c4999e Revert "[hwasan] Record and display stack history in stack-based reports."This reverts commit r342921: test failures on clang-cmake-arm* bots.llvm-svn: 342922 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Mon, 24 Sep 2018 22:50:32 +0000 Evgeniy Stepanov <eugeni.stepanov@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#9043e17e [hwasan] Record and display stack history in stack-based reports.Summary:Display a list of recent stack frames (not a stack trace!) whentag-mismatch is detected on a stack address.The implementation uses alignment tricks to get both the address ofthe history buffer, and the base address of the shadow with a single8-byte load. See the comment in hwasan_thread_list.h for moredetails.Developed in collaboration with Kostya Serebryany.Reviewers: kccSubscribers: srhines, kubamracek, mgorny, hiraditya, jfb, llvm-commitsDifferential Revision: https://reviews.llvm.org/D52249llvm-svn: 342921 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Mon, 24 Sep 2018 21:38:42 +0000 Evgeniy Stepanov <eugeni.stepanov@gmail.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#99cf54ba [HWASan] Introduce non-zero based and dynamic shadow memory (LLVM).Summary:Support the dynamic shadow memory offset (the default case for userspace now) and static non-zero shadow memory offset(-hwasan-mapping-offset option). Keeping the the latter case aroundfor functionality and performance comparison tests (and mostly for-hwasan-mapping-offset=0 case).The implementation is stripped down ASan one, picking only the relevantparts in the following assumptions: shadow scale is fixed, the shadowmemory is dynamic, it is accessed via ifunc global, shadow memory addressrematerialization is suppressed.Keep zero-based shadow memory for kernel (-hwasan-kernel option) andcalls instreumented case (-hwasan-instrument-with-calls option), whichessentially means that the generated code is not changed in these cases.Reviewers: eugenisSubscribers: srhines, llvm-commitsDifferential Revision: https://reviews.llvm.org/D45840llvm-svn: 330475 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Fri, 20 Apr 2018 20:04:04 +0000 Alex Shlyapnikov <alekseys@google.com> http://172.16.0.5:8080/history/llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll#43271b18 [hwasan] Fix inline instrumentation.This patch changes hwasan inline instrumentation:Fixes address untagging for shadow address calculation (use 0xFF instead of 0x00 for the top byte).Emits brk instruction instead of hlt for the kernel and user space.Use 0x900 instead of 0x100 for brk immediate (0x100 - 0x800 are unavailable in the kernel).Fixes and adds appropriate tests.Patch by Andrey Konovalov.Differential Revision: https://reviews.llvm.org/D43135llvm-svn: 325711 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/HWAddressSanitizer/basic.ll Wed, 21 Feb 2018 19:52:23 +0000 Evgeniy Stepanov <eugeni.stepanov@gmail.com>