[llvm-bugs] [Bug 48064] New: [StackColoring] Need Conservatively merge point pV = &(&Variable) in catch(Variable)
via llvm-bugs
llvm-bugs at lists.llvm.org
Tue Nov 3 16:38:13 PST 2020
https://bugs.llvm.org/show_bug.cgi?id=48064
Bug ID: 48064
Summary: [StackColoring] Need Conservatively merge point pV =
&(&Variable) in catch(Variable)
Product: libraries
Version: trunk
Hardware: PC
OS: Windows NT
Status: NEW
Severity: normal
Priority: P
Component: Common Code Generator Code
Assignee: unassignedbugs at nondot.org
Reporter: xiang1.zhang at intel.com
CC: llvm-bugs at lists.llvm.org
We need conservatively merge pV = &(&Variable) for catch(Variable), EH libs may
write the catch value and return the Point (Type**) pV back.
This Point may be dangerously over written due to some work of objects'
destructor in try block. (The destructor may work after EH written)
In fact, for the catch point pV, there is usually a very long life range
guarded with TIME_START and TIME_END (usually almost through the whole
program),
but there is an potion "-stackcoloring-lifetime-start-on-first-use" which will
cut it shorter.
We should let pV conservatively use its TIME_START and TIME_END as its
live-range, not affected by the option
"-stackcoloring-lifetime-start-on-first-use"
We find this bug in a big win32 project, now the following case can reproduce.
Compile with: clang-cl -m32 -O2 -EHs test.cpp
test.cpp:
__attribute__((noinline,nothrow,weak)) void escape(int *p) { }
struct object {
int i;
object() {
i = 1;
}
~object() {
// if "object" and "exp" are assigned to the same slot,
// this assign will corrupt "exp".
i = 9999;
escape(&i);
}
};
inline void throwit() { throw 999; }
volatile int v;
inline void func() {
try {
object o;
throwit();
}
// "exp" is written by the OS when the "throw" occurs.
// Then the destructor is called, and the store-assign
// clobbers the value of "exp".
// The dereference of "exp" (with value 9999) causes a crash.
catch (int &exp) {
v = exp;
}
}
int main() {
func();
return 0;
}
//////////////////
Now we already have a patch to handle this. (https://reviews.llvm.org/D86673)
--
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/20201104/5f8a4a6e/attachment.html>
More information about the llvm-bugs
mailing list