search for: handle_sigfp

> -----Original Message----- > From: Cameron McInally <cameron.mcinally at nyu.edu> > Sent: Friday, June 14, 2019 4:02 PM > To: Eli Friedman <efriedma at quicinc.com>; LLVM Developers Mailing List <llvm- > dev at lists.llvm.org> > Cc: Craig Topper <craig.topper at gmail.com>; Kaylor, Andrew > <andrew.kaylor at intel.com> > Subject: [EXT]

On Fri, Jul 31, 2015 at 5:15 AM, Karl Skomski <karl at skomski.com> wrote: > Would it make sense to add the possibility to print a stacktrace also on > SIGFPE and not only on SIGSEGV or SIGBUS? > Yes, under a separate flag (handle_sigfpe=1). I think it's fine to have this flag on by default. Would you like to contribute a patch? > Only noticed that LibFuzzer doesn't generate any crash report because asan > is not handling the signal. > Makes sense. The sanitizers (except maybe a bit of ubsan) typically don'...

Would it make sense to add the possibility to print a stacktrace also on SIGFPE and not only on SIGSEGV or SIGBUS? Only noticed that LibFuzzer doesn't generate any crash report because asan is not handling the signal. Kind regards, Karl Skomski -------------- next part -------------- An HTML attachment was scrubbed... URL:

...ou really need a "real" trap, I guess we could expose the x86 idiv as an intrinsic. A real trap would be preferred. I suspect that it would be difficult/expensive to set all the flags correctly (if that's even possible). E.g.: #include <stdio.h> #include <signal.h> void handle_sigfpe(int fpe) { printf("Caught signal %d\n", fpe); } int main (void) { signal(SIGFPE, handle_sigfpe); #if TRAP int x = 1/0; #else raise(SIGFPE); #endif return 0; } In this pathological case, the RF flag differs so we'll see an infinite loop. -------------- next part ----------...