User Details
- User Since
- Apr 16 2014, 9:28 AM (365 w, 6 d)
Jan 11 2018
Ping! Is this stalling on reviewer attention? If so, please submit to LLVM Weekly's review corner (assuming it works with current LLVM), see http://llvmweekly.org/reviewcorner for details.
Dec 8 2017
Okay, that makes sense. Thanks for accommodating my use-case anyway! :D.
Hmm, this change means very recent LLVM is required to build libunwind-- previously I was able to use recent libunwind/libcxx/libcxxabi with LLVM 5 and LLVM 4.
Oct 19 2017
Wow, I've finally debugged some unwind failures to this on x86_64 Linux ...
- Call-frame optimization introduces it
- This fixes the cases I was investigating!!
Jul 13 2017
Jun 13 2017
Don't mean to block this, but just FYI I won't be able to look into this carefully until later this week (sorry!).
Jun 12 2017
Sorry for missing this originally, as a perhaps interesting note:
the checks were extracted from a research prototype that worked at the IR level --where pointer itself is unsigned but the offsets (including the computed total offset) is a signed expression[1].
(we also tracked conversions and whatnot, so... well things were different. Anyway, sorry for missing this!)
May 29 2017
I've built quite a bit with this (ground-up Linux distribution) which attests to it being fairly robust (no crashing or new errors not experienced with unpatched clang) and the bugs found so far are all true positives (few of which were caught and reported last time around).
May 17 2017
May 9 2017
Feb 24 2017
Sorry for the delay!
Feb 14 2017
Feb 9 2017
After some thought, can we discuss why this is a good idea?
I've been bitten when attempting to use existence/nature of casts in the AST to reason about the original code, but this looks like it does the right thing in all the situations I can think of.
Jan 28 2017
Jan 27 2017
Looks like this was fixed for NVPTX in r293256, Hexagon earlier. Can confirm resolves the issue I was encountering, thanks!
Jan 26 2017
Breaks build on other platforms too, for example: http://lab.llvm.org:8011/builders/clang-ppc64be-linux-multistage/builds/1928/steps/build%20stage%201/logs/stdio
Jan 24 2017
Thanks for the fix!
Jan 21 2017
+1, I've been using trunk with this revision reverted since I need liblldELF as well. Would it fix all use cases if we added bits to install the libraries to add_lld_library?
May 17 2016
Fixed test:
// RUN: %clangxx -fsanitize=pointer-overflow %s -o %t // RUN: %t 1 2>&1 | FileCheck %s --check-prefix=ERR // RUN: %t 0 2>&1 | FileCheck %s --check-prefix=SAFE // RUN: %t -1 2>&1 | FileCheck %s --check-prefix=SAFE
Hmm, this test actually is wonky if argv[0] happens to be negative when represented as intptr_t... which happens on -m32 for my machine. I'll see about constructing a better test case!