This is an archive of the discontinued LLVM Phabricator instance.

[asan] Remove debug locations from alloca prologue instrumentation
ClosedPublic

Authored by johannes on Dec 2 2019, 4:44 AM.

Details

Summary

This fixes https://llvm.org/PR26673
"Wrong debugging information with -fsanitize=address"
where asan instrumentation causes the prologue end to be computed
incorrectly: findPrologueEndLoc, looks for the first instruction
with a debug location to determine the prologue end. Since the asan
instrumentation instructions had debug locations, that prologue end was
at some instruction, where the stack frame is still being set up.

There seems to be no good reason for extra debug locations for the
asan instrumentations that set up the frame; they don't have a natural
source location. In the debugger they are simply located at the start
of the function.

For certain other instrumentations like -fsanitize-coverage=trace-pc-guard
the same problem persists - that might be more work to fix, since it
looks 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 is
given the correct source location; as the debug location is still set in
ModuleSanitizerCoverage::InjectCoverageAtBlock, the test does not break.
So -fsanitize-coverage is hopefully unaffected - I don't think it should
rely 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

Diff Detail

Event Timeline

johannes created this revision.Dec 2 2019, 4:44 AM
Herald added a project: Restricted Project. · View Herald TranscriptDec 2 2019, 4:44 AM
johannes edited the summary of this revision. (Show Details)Dec 2 2019, 5:11 AM
johannes edited the summary of this revision. (Show Details)
vsk added a subscriber: vsk.Dec 2 2019, 9:08 AM

Looks reasonable to me, but I'll let someone more familiar with asan give an lgtm.

llvm/test/Instrumentation/AddressSanitizer/debug-info-alloca.ll
2

nit: s/asan instrumentation/asan prologue/ ?

aprantl added inline comments.Dec 2 2019, 1:41 PM
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
2999

Can there be calls anywhere in the prologue? If yes, this may cause a verifier error i any of these calls get inlined. What does the commit message for the deleted statements say?

eugenis accepted this revision.Dec 2 2019, 3:24 PM

I think this is fine. The original change was about the coverage callback location.

llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
2999

Yes, but they can not be inlined.

This revision is now accepted and ready to land.Dec 2 2019, 3:24 PM
vsk added inline comments.Dec 2 2019, 3:30 PM
llvm/lib/Transforms/Instrumentation/AddressSanitizer.cpp
2999

Yeah, so long as these callees have no DISubprogram (and I don't see why they would) there should be no verifier issues.

johannes updated this revision to Diff 231849.Dec 3 2019, 2:10 AM
johannes edited the summary of this revision. (Show Details)
johannes removed a subscriber: vsk.

update comment and commit message

This revision was automatically updated to reflect the committed changes.
johannes marked an inline comment as done.