[llvm-bugs] [Bug 46300] New: AddressSanitizer globals instrumentation causes ELF info to change size of symbol
via llvm-bugs
llvm-bugs at lists.llvm.org
Fri Jun 12 04:10:30 PDT 2020
https://bugs.llvm.org/show_bug.cgi?id=46300
Bug ID: 46300
Summary: AddressSanitizer globals instrumentation causes ELF
info to change size of symbol
Product: compiler-rt
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: asan
Assignee: unassignedbugs at nondot.org
Reporter: elver at google.com
CC: llvm-bugs at lists.llvm.org
When instrumenting globals, ASan adds redzones by replacing the globals with a
new one that has the redzones added to them. LLVM then, correctly, coveys this
information as-is and the global symbol will show up with the new size in ELF
(and likely other binary formats) symbol information.
This may cause problems for programs that somehow scan other binaries' symbol
information and rely on the usable (without redzone) size to be presented only.
This was first caught in: https://github.com/ClangBuiltLinux/linux/issues/1045
To fix, we need to ensure that global variables' symbol information will show
up in ELF symbol tables like they would without ASan instrumentation, i.e.
hiding the fact that there is a redzone.
Evgenii Stepanov suggests:
> target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
> target triple = "x86_64-unknown-linux-gnu"
>
> @x_ = private global i64 0, align 8
> @y_ = private global i64 0, align 8
>
> @x = dso_local alias i32, bitcast (i64* @y_ to i32*)
> module asm ".size x, 4"
> @y = dso_local alias i32, bitcast (i64* @y_ to i32*)
> module asm ".size y, 4"
>
> Alternatively, we could build a way to communicate the desired symbol size to the MC layer. It could use metadata, or maybe we could even make aliases emit .size directives unconditionally.
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200612/4b3421a7/attachment.html>
More information about the llvm-bugs
mailing list