[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