Fix build error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')

[xiangzhai]

Summary

Hi LLVM developers,

Resurrect pselect MainLoop implementation https://reviews.llvm.org/D32600 commited by Pavel, then it failed to build for Linux:

/data/project/LLVM/llvm/tools/lldb/source/Host/common/MainLoop.cpp:158:10: error: no viable conversion from returned value of type 'int' to function return type 'sigset_t' (aka '__sigset_t')
  return 0;
         ^
/usr/include/bits/sigset.h:27:9: note: candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const __sigset_t &' for 1st argument
typedef struct
        ^
/usr/include/bits/sigset.h:27:9: note: candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to '__sigset_t &&' for 1st argument
1 error generated.

So I simply changed the return value, please review my patch and point out my fault, thanks a lot!

Regards,
Leslie Zhai

[labath]

This will not compile on windows, which really is the only branch we expected to have SIGNAL_POLLING_UNSUPPORTED set. In this sense Pauls (cc'ed) fix is better, but it does not actually get lldb going on the affected systems. Could one of you guys check whether you really don't have the ppoll syscall (for example, are able to compile a simple program using ppoll (*)). If you really don't have ppoll, then I can hook up cmake so it falls back to pselect. If you do, then I may need a bit more help to debug the cmake detection logic.

thank a lot.

(*) this will do the trick:

#define _GNU_SOURCE
#include <poll.h>
int main() { return ppoll(0, 0, 0, 0); }

[xiangzhai]

Hi Pavel,

Could one of you guys check whether you really don't have the ppoll syscall (for example, are able to compile a simple program using ppoll (*))

It has! clang is able to compile the simple program!

If you do, then I may need a bit more help to debug the cmake detection logic

Yes, it needs to add the detection logic in the CMakeLists.txt :)

Regards,
Leslie Zhai

[labath]

In D32787#744379, @xiangzhai wrote:

Hi Pavel,

Could one of you guys check whether you really don't have the ppoll syscall (for example, are able to compile a simple program using ppoll (*))

It has! clang is able to compile the simple program!

If you do, then I may need a bit more help to debug the cmake detection logic

Yes, it needs to add the detection logic in the CMakeLists.txt :)

We already have it, it's in lldb/cmake/modules/LLDBGenerateConfig.cmake. We need to figure out why it's not working.

If you have some experience with cmake, it would be easiest if you could investigate yourself. Otherwise we'll have to do some remote debugging. If you can send me your CMakeError.log and CMakeOutput.log, I may be able to figure out what's going on.

[probinson]

Looking at CMakeError.log, the test program does #include <poll.h> but does not #define _GNU_SOURCE. The define has to be there for your example to compile on my Ubuntu.

[labath]

In D32787#744974, @probinson wrote:

Looking at CMakeError.log, the test program does #include <poll.h> but does not #define _GNU_SOURCE. The define has to be there for your example to compile on my Ubuntu.

We do that in LLDBGenerateConfig.cmake:7.

However, a previous version of the ppoll patch did not have the correct define. Could it be that you just have stale cmake cache?

[probinson]

In D32787#745099, @labath wrote:

Could it be that you just have stale cmake cache?

That could easily be true. Rerunning cmake didn't fix it; short of deleting the entire build directory, is there a way to refresh the cache?

[labath]

In D32787#745139, @probinson wrote:

In D32787#745099, @labath wrote:

Could it be that you just have stale cmake cache?

That could easily be true. Rerunning cmake didn't fix it; short of deleting the entire build directory, is there a way to refresh the cache?

Opening the CMakeCache.txt, and deleting the HAVE_PPOLL line should re-trigger the detection. But if that doesn't fix it, I'd certainly recommend nuking the build directory before looking for problems elsewhere.

[probinson]

In D32787#745205, @labath wrote:

In D32787#745139, @probinson wrote:

In D32787#745099, @labath wrote:

Could it be that you just have stale cmake cache?

That could easily be true. Rerunning cmake didn't fix it; short of deleting the entire build directory, is there a way to refresh the cache?

Opening the CMakeCache.txt, and deleting the HAVE_PPOLL line should re-trigger the detection. But if that doesn't fix it, I'd certainly recommend nuking the build directory before looking for problems elsewhere.

Yes, that worked. Which leaves the original source-text problem, of course, but at least I'm not having to maintain a local patch anymore.
Thanks!

[xiangzhai]

Opening the CMakeCache.txt, and deleting the HAVE_PPOLL line should re-trigger the detection

Fixed!

source/Host/common/MainLoop.cpp

 std::unique_ptr<MainLoop::RunImpl> MainLoop::RunImpl::Create(MainLoop &loop, Error &error)
 {
   error.Clear();
   return std::unique_ptr<RunImpl>(new RunImpl(loop));
 }
 
 sigset_t MainLoop::RunImpl::get_sigmask() {
 #if SIGNAL_POLLING_UNSUPPORTED
-  return 0;
+  sigset_t sigmask;
+  memset(sigmask.__val, 0, _SIGSET_NWORDS);
+  return sigmask;
 #else
   sigset_t sigmask;
   int ret = pthread_sigmask(SIG_SETMASK, nullptr, &sigmask);
   assert(ret == 0);
   (void) ret;
 
   for (const auto &sig : loop.m_signals) {
     signals.push_back(sig.first);