> We do not implement that restricted semantics correctly either -- see > https://bugs.llvm.org/show_bug.cgi?id=27190Haha, I wondered for a minute whether I should bring up that bug... We've seen pretty nasty crashes due to it and had to work around it..... One of my recent work has also uncovered another (I believe) invalid handling of returns_twice functions.... https://bugs.llvm.org/show_bug.cgi?id=35211 noalias returns seems to be treated as stack allocation but is not required by either LangRef or C standard to be so for returns_twice function handling....> IMO the Right(TM) fix is to add a CFG edge from all possibly > longjmp'ing function calls to all setjmps in a function. We can > probably do this by modeling the possibly longjmp'ing calls as invokes > that unwind to a special "setjmp" landingpad.This seems to be a way to handle setjmp without requiring volatile anywhere? We've thought about doing that ourselves a little but decided that it was too complicated compare to the left over issue after the crash was worked around and it's also hard to make it handle longjmp's from signal handlers very well....
On Sun, Nov 05, 2017 at 09:22:47PM -0500, Yichao Yu via llvm-dev wrote:> > We do not implement that restricted semantics correctly either -- see > > https://bugs.llvm.org/show_bug.cgi?id=27190 > > Haha, I wondered for a minute whether I should bring up that bug... > We've seen pretty nasty crashes due to it and had to work around > it..... > > One of my recent work has also uncovered another (I believe) invalid > handling of returns_twice functions.... > https://bugs.llvm.org/show_bug.cgi?id=35211 > noalias returns seems to be treated as stack allocation but is not > required by either LangRef or C standard to be so for returns_twice > function handling....For the record, function returning twice are not even correctly annotated by glibc, see https://sourceware.org/bugzilla/show_bug.cgi?id=20382 Looks like gcc handles that using a pattern matching approach (see https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01163.html) Maybe we should do so too?
On 11/6/2017 7:07 AM, Serge Guelton via llvm-dev wrote:> On Sun, Nov 05, 2017 at 09:22:47PM -0500, Yichao Yu via llvm-dev wrote: >>> We do not implement that restricted semantics correctly either -- see >>> https://bugs.llvm.org/show_bug.cgi?id=27190 >> Haha, I wondered for a minute whether I should bring up that bug... >> We've seen pretty nasty crashes due to it and had to work around >> it..... >> >> One of my recent work has also uncovered another (I believe) invalid >> handling of returns_twice functions.... >> https://bugs.llvm.org/show_bug.cgi?id=35211 >> noalias returns seems to be treated as stack allocation but is not >> required by either LangRef or C standard to be so for returns_twice >> function handling.... > For the record, function returning twice are not even correctly > annotated by glibc, see https://sourceware.org/bugzilla/show_bug.cgi?id=20382 > > Looks like gcc handles that using a pattern matching approach > (see https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01163.html) > > Maybe we should do so too?We already have code in clang to mark calls to setjmp/sigsetjmp/etc. returns_twice. -Eli -- Employee of Qualcomm Innovation Center, Inc. Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux Foundation Collaborative Project