Page MenuHomePhabricator

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

Authored by xiangzhai on May 3 2017, 12:56 AM.

Details

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

Diff Detail

Repository
rL LLVM

Event Timeline

xiangzhai created this revision.May 3 2017, 12:56 AM
labath requested changes to this revision.May 3 2017, 2:26 AM
labath added a subscriber: probinson.

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); }
This revision now requires changes to proceed.May 3 2017, 2:26 AM

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 added a comment.May 3 2017, 2:58 AM

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.

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.

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?

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?

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.

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 abandoned this revision.May 3 2017, 7:10 PM

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

Fixed!