Changes in local_stack_base.ll

b7fd30ea - [ASan] Removed unused AddressSanitizerPass functional pass.

Mon, 28 Feb 2022 20:38:31 +0000

[ASan] Removed unused AddressSanitizerPass functional pass.This is a clean-up patch. The functional pass was rolled into the module pass in D112732.Reviewed By: vitalybuka, aeubanksDifferential Revision: https://reviews.llvm.org/D120674 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll

0df277a1 - [test] Remove some legacy PM tests in llvm/test/Instrumentation/AddressSanitizer

Sun, 05 Sep 2021 19:02:31 +0000

[test] Remove some legacy PM tests in llvm/test/Instrumentation/AddressSanitizer List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll

7c2f2762 - [NewPM][ASan] Make ASan tests work under NPM

Sat, 18 Jul 2020 00:49:46 +0000

[NewPM][ASan] Make ASan tests work under NPMUnder NPM, the asan-globals-md analysis is required but cannot be runwithin the asan function pass due to module analyses not being able torun from a function pass. So this pins all tests using "-asan" to thelegacy PM and adds a corresponding RUN line with-passes='require,function(asan)'.Now all tests in Instrumentation/AddressSanitizer pass when-enable-new-pm is by default on.Tests were automatically converted using the following python script andfailures were manually fixed up.import sysfor i in sys.argv: with open(i, 'r') as f: s = f.read() with open(i, 'w') as f: for l in s.splitlines(): if "RUN:" in l and ' -asan -asan-module ' in l and '\\' not in l: f.write(l.replace(' -asan -asan-module ', ' -asan -asan-module -enable-new-pm=0 ')) f.write('\n') f.write(l.replace(' -asan -asan-module ', " -passes='require,function(asan),module(asan-module)' ")) f.write('\n') elif "RUN:" in l and ' -asan ' in l and '\\' not in l: f.write(l.replace(' -asan ', ' -asan -enable-new-pm=0 ')) f.write('\n') f.write(l.replace(' -asan ', " -passes='require,function(asan)' ")) f.write('\n') else: f.write(l) f.write('\n')See https://bugs.llvm.org/show_bug.cgi?id=46611.Reviewed By: vitalybukaDifferential Revision: https://reviews.llvm.org/D83921 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll

8e77b33b - [Local] Do not move around dbg.declares during replaceDbgDeclare

Mon, 10 Feb 2020 23:37:56 +0000

[Local] Do not move around dbg.declares during replaceDbgDeclarereplaceDbgDeclare is used to update the descriptions of stack variableswhen they are moved (e.g. by ASan or SafeStack). A side effect ofreplaceDbgDeclare is that it moves dbg.declares around in theinstruction stream (typically by hoisting them into the entry block).This behavior was introduced in llvm/r227544 to fix an assertion failure(llvm.org/PR22386), but no longer appears to be necessary.Hoisting a dbg.declare generally does not create problems. Usually,dbg.declare either describes an argument or an alloca in the entryblock, and backends have special handling to emit locations for these.In optimized builds, LowerDbgDeclare places dbg.values in the rightspots regardless of where the dbg.declare is. And no one usesreplaceDbgDeclare to handle things like VLAs.However, there doesn't seem to be a positive case for movingdbg.declares around anymore, and this reordering can get in the way ofunderstanding other bugs. I propose getting rid of it.Testing: stage2 RelWithDebInfo sanitized build, check-llvmrdar://59397340Differential Revision: https://reviews.llvm.org/D74517 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll

09667bc1 - [asan] Remove debug locations from alloca prologue instrumentation

Mon, 02 Dec 2019 10:39:28 +0000

[asan] Remove debug locations from alloca prologue instrumentationSummary:This fixes https://llvm.org/PR26673"Wrong debugging information with -fsanitize=address"where asan instrumentation causes the prologue end to be computedincorrectly: findPrologueEndLoc, looks for the first instructionwith a debug location to determine the prologue end. Since the asaninstrumentation instructions had debug locations, that prologue end wasat some instruction, where the stack frame is still being set up.There seems to be no good reason for extra debug locations for theasan instrumentations that set up the frame; they don't have a naturalsource location. In the debugger they are simply located at the startof the function.For certain other instrumentations like -fsanitize-coverage=trace-pc-guardthe same problem persists - that might be more work to fix, since itlooks like they rely on locations of the tracee functions.This partly reverts aaf4bb239487e0a3b20a8eaf94fc641235ba2c29"[asan] Set debug location in ASan function prologue"whose motivation was to give debug location info to the coverage callback.Its test only ensures that the call to @__sanitizer_cov_trace_pc_guard isgiven the correct source location; as the debug location is still set inModuleSanitizerCoverage::InjectCoverageAtBlock, the test does not break.So -fsanitize-coverage is hopefully unaffected - I don't think it shouldrely on the debug locations of asan-generated allocas.Related revision: 3c6c14d14b40adfb581940859ede1ac7d8ceae7a"ASAN: Provide reliable debug info for local variables at -O0."Below is how the X86 assembly version of the added test case changes.We get rid of some .loc lines and put prologue_end where the user code starts.```diff--- 2.master.s 2019-12-02 12:32:38.982959053 +0100+++ 2.patch.s 2019-12-02 12:32:41.106246674 +0100@@ -45,8 +45,6 @@ .cfi_offset %rbx, -24 xorl %eax, %eax movl %eax, %ecx- .Ltmp2:- .loc 1 3 0 prologue_end # 2.c:3:0 cmpl $0, __asan_option_detect_stack_use_after_return movl %edi, 92(%rbx) # 4-byte Spill movq %rsi, 80(%rbx) # 8-byte Spill@@ -57,9 +55,7 @@ callq __asan_stack_malloc_0 movq %rax, 72(%rbx) # 8-byte Spill .LBB1_2:- .loc 1 0 0 is_stmt 0 # 2.c:0:0 movq 72(%rbx), %rax # 8-byte Reload- .loc 1 3 0 # 2.c:3:0 cmpq $0, %rax movq %rax, %rcx movq %rax, 64(%rbx) # 8-byte Spill@@ -72,9 +68,7 @@ movq %rax, %rsp movq %rax, 56(%rbx) # 8-byte Spill .LBB1_4:- .loc 1 0 0 # 2.c:0:0 movq 56(%rbx), %rax # 8-byte Reload- .loc 1 3 0 # 2.c:3:0 movq %rax, 120(%rbx) movq %rax, %rcx addq $32, %rcx@@ -99,7 +93,6 @@ movb %r8b, 31(%rbx) # 1-byte Spill je .LBB1_7 # %bb.5:- .loc 1 0 0 # 2.c:0:0 movq 40(%rbx), %rax # 8-byte Reload andq $7, %rax addq $3, %rax@@ -118,7 +111,8 @@ movl %ecx, (%rax) movq 80(%rbx), %rdx # 8-byte Reload movq %rdx, 128(%rbx)- .loc 1 4 3 is_stmt 1 # 2.c:4:3+.Ltmp2:+ .loc 1 4 3 prologue_end # 2.c:4:3 movq %rax, %rdi callq f movq 48(%rbx), %rax # 8-byte Reload```Reviewers: eugenis, aprantlReviewed By: eugenisSubscribers: ormris, aprantl, hiraditya, llvm-commitsTags: #llvmDifferential Revision: https://reviews.llvm.org/D70894 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll

2c864551 - [DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.

Wed, 09 May 2018 02:40:45 +0000

[DebugInfo] Add DILabel metadata and intrinsic llvm.dbg.label.In order to set breakpoints on labels and list source code aroundlabels, we need collect debug information for labels, i.e., labelname, the function label belong, line number in the file, and theaddress label located. In order to keep these information in LLVMIR and to allow backend to generate debug information correctly.We create a new kind of metadata for labels, DILabel. The formatof DILabel is!DILabel(scope: !1, name: "foo", file: !2, line: 3)We hope to keep debug information as much as possible even thecode is optimized. So, we create a new kind of intrinsic for labelmetadata to avoid the metadata is eliminated with basic block.The intrinsic will keep existing if we keep it from optimized out.The format of the intrinsic isllvm.dbg.label(metadata !1)It has only one argument, that is the DILabel metadata. Theintrinsic will follow the label immediately. Backend could get thelabel metadata through the intrinsic's parameter.We also create DIBuilder API for labels to be used by Frontend.Frontend could use createLabel() to allocate DILabel objects, and useinsertLabel() to insert llvm.dbg.label intrinsic in LLVM IR.Differential Revision: https://reviews.llvm.org/D45024Patch by Hsiangkai Wang.llvm-svn: 331841 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll

3c6c14d1 - ASAN: Provide reliable debug info for local variables at -O0.

Mon, 11 Dec 2017 20:43:21 +0000

ASAN: Provide reliable debug info for local variables at -O0.The function stack poisioner conditionally stores local variableseither in an alloca or in malloc'ated memory, which has theunfortunate side-effect, that the actual address of the variable isonly materialized when the variable is accessed, which means thatthose variables are mostly invisible to the debugger even whencompiling without optimizations.This patch stores the address of the local stack base into an alloca,which can be referred to by the debug info and is available throughoutthe function. This adds one extra pointer-sized alloca to each stackframe (but mem2reg can optimize it away again when optimizations areenabled, yielding roughly the same debug info quality as before inoptimized code).rdar://problem/30433661Differential Revision: https://reviews.llvm.org/D41034llvm-svn: 320415 List of files: /llvm-project-15.0.7/llvm/test/Instrumentation/AddressSanitizer/local_stack_base.ll