Windows comes with an extremely limited implementation of signal which only supports a few signal values. Of importance to LLDB is the SIGINT value which invokes a callback when the user presses Ctrl+C. For some reason, we were completely redefining the signal() function to intercept SIGINT and use our own custom processing of Ctrl+C rather than use the builtin processing of Ctrl+C done by signal(). This is frought with peril for a number of reasons:
- Depending on order of includes, you could get into a situation where both builtin signal() and our own custom signal() are defined, leading to multiply defined symbol errors at link time.
- It leads to a bunch of compiler warnings, since we end up redefining the same constants (e.g. SIG_DFL etc) because we were going through hoops to avoid #including the standard headers (even though that doesn't work)
- The standard implementation of signal() actually does exactly what you would expect it to do with regards to Ctrl+C. In fact, by looking at the source code of the CRT, you can see that for SIGINT it actually just calls SetConsoleCtrlHandler, which is exactly what our own custom implementation of signal did!
So, we simply remove all of our custom windows versions of signal() and use the builtin implementation. Code that attempts to call signal() with values that are not supported on Windows are handled by preprocessor defines