Include <sys/cdefs.h> in execinfo.h

[arichardson]

Summary

Otherwise the LLVM CMake configure step does not detect that backtrace()
is available:

/local/scratch/alr48/cheri/output/sdk/sysroot128/usr/include/execinfo.h:37:1: error: unknown type name 'BEGIN_
DECLS'
BEGIN_DECLS
^
/local/scratch/alr48/cheri/output/sdk/sysroot128/usr/include/execinfo.h:38:7: error: expected ';' after top leve
l declarator
size_t backtrace(void **, size_t);

^

/local/scratch/alr48/cheri/output/sdk/sysroot128/usr/include/execinfo.h:43:1: error: unknown type name 'END_DECLS'
END_DECLS
^
CheckSymbolExists.c:8:19: error: use of undeclared identifier 'backtrace'

return ((int*)(&backtrace))[argc];
                ^

4 errors generated.
ninja: build stopped: subcommand failed.

File /local/scratch/alr48/cheri/build/llvm-project-mips-hybrid128-build/CMakeFiles/CMakeTmp/CheckSymbolExists.c:
/* */
#include <execinfo.h>

int main(int argc, char** argv)
{

(void)argv;

#ifndef backtrace

return ((int*)(&backtrace))[argc];

#else

(void)argc;
return 0;

#endif
}

[emaste]

Fine with me.

[cem]

This is for cross-building?

FreeBSD's stddef.h includes sys/cdefs.h. If you aren't finding FreeBSD's stddef.h in a cross build, why would you expect to find FreeBSD's sys/cdefs.h?

I guess glibc's sys/cdefs.h includes __BEGIN_DECLS, etc, but I don't know how portable that assumption is (no idea what MacOS has, and I don't know if windows environments like mingw64 have a sys/cdefs.h).

I'd prefer a more holistic approach — use the src tree FreeBSD's headers when we're cross-compiling, rather than the host's.

[cem]

Mark NACK for now. Maybe I misunderstand what is possible or something, help me understand :-).

[arichardson]

In D22630#497926, @cem wrote:

This is for cross-building?

FreeBSD's stddef.h includes sys/cdefs.h. If you aren't finding FreeBSD's stddef.h in a cross build, why would you expect to find FreeBSD's sys/cdefs.h?

I guess glibc's sys/cdefs.h includes __BEGIN_DECLS, etc, but I don't know how portable that assumption is (no idea what MacOS has, and I don't know if windows environments like mingw64 have a sys/cdefs.h).

I'd prefer a more holistic approach — use the src tree FreeBSD's headers when we're cross-compiling, rather than the host's.

Good catch, I didn't realize that stddef includes cdefs.h.

This happens when building llvm for cheribsd/MIPS on a x86 host. I have no idea why it's not pulling in cdefs.h. Possibly the build is using the compiler-provided stddef.h instead of the one from the sysroot. I'll investigate.

[arichardson]

Turns out that clang always searches the builtin headers first and it only happens to work because the base/ports clang doesn't install stddef.h:

$ echo '#include <execinfo.h>' | /usr/local/bin/clang10 --target=mips64-unknown-freebsd13 --sysroot=$HOME/cheri/output/sdk/sysroot128 -target mips64-unknown-freebsd13 -pipe -integrated-as -G0 -msoft-float -mabi=n64 -o /dev/null -c -xc - -v
clang version 10.0.1
Target: mips64-unknown-freebsd13
Thread model: posix
InstalledDir: /usr/local/llvm10/bin
 (in-process)
 "/usr/local/llvm10/bin/clang" -cc1 -triple mips64-unknown-freebsd13 -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -discard-value-names -main-file-name - -mrelocation-model pic -pic-level 1 -mthread-model posix -mframe-pointer=all -fno-rounding-math -masm-verbose -mconstructor-aliases -munwind-tables -target-cpu mips3 -target-feature -noabicalls -target-feature +soft-float -target-abi n64 -msoft-float -mfloat-abi soft -mllvm -mips-ssection-threshold=0 -dwarf-column-info -fno-split-dwarf-inlining -debugger-tuning=gdb -v -resource-dir /usr/local/llvm10/lib/clang/10.0.1 -isysroot /home/alr48/cheri/output/sdk/sysroot128 -fdebug-compilation-dir /home/alr48 -ferror-limit 19 -fmessage-length 209 -fgnuc-version=4.2.1 -fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -faddrsig -o /dev/null -x c -
clang -cc1 version 10.0.1 based upon LLVM 10.0.1 default target x86_64-portbld-freebsd12.1
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/llvm10/lib/clang/10.0.1/include
 /home/alr48/cheri/output/sdk/sysroot128/usr/include
End of search list.

$ ls /usr/local/llvm10/lib/clang/10.0.1/include/stddef.h
ls: /usr/local/llvm10/lib/clang/10.0.1/include/stddef.h: No such file or directory

Whereas for our CHERI clang we *do* install stddef.h so that is picked up instead.

[brooks]

Hmm, why isn't -nobuiltininc -idirafter ${COMPILER_RESOURCE_DIR}/include included here.

[arichardson]

In D22630#577433, @brooks wrote:

Hmm, why isn't -nobuiltininc -idirafter ${COMPILER_RESOURCE_DIR}/include included here.

I was building upstream LLVM using their CMakeLists.txt so it won't pull in the bsd.foo.mk flags.

[arichardson]

Can this be committed, so this header is standalone even if you don't use a patched LLVM?