Compiling for AArch64 fails with glibc 2.25

[lgeek]

DynamoRIO commit: 4afa0bd
Building on an up-to-date Arch Linux ARM (aarch64) system with glibc 2.25 and gcc 6.3.1

Output:

[  2%] Building C object core/CMakeFiles/dynamorio_static.dir/unix/signal.c.o
In file included from /usr/include/signal.h:325:0,
                 from /home/cosmin/dynamorio/core/lib/globals_shared.h:126,
                 from /home/cosmin/dynamorio/core/unix/../globals.h:90,
                 from /home/cosmin/dynamorio/core/unix/signal_private.h:51,
                 from /home/cosmin/dynamorio/core/unix/signal.c:45:
/usr/include/sys/ucontext.h:55:16: error: field ‘uc_mcontext’ has incomplete type
     mcontext_t uc_mcontext;
                ^~~~~~~~~~~
In file included from /home/cosmin/dynamorio/core/unix/signal.c:45:0:
/home/cosmin/dynamorio/core/unix/signal_private.h:159:23: error: field ‘uc_mcontext’ has incomplete type
     sigcontext_t      uc_mcontext; /* last for future expansion */
                       ^~~~~~~~~~~
/home/cosmin/dynamorio/core/unix/signal.c: In function ‘sigcontext_to_mcontext’:
/home/cosmin/dynamorio/core/unix/signal.c:2233:24: error: dereferencing pointer to incomplete type ‘sigcontext_t {aka struct sigcontext}’
     memcpy(&mc->r0, &sc->SC_FIELD(regs[0]), sizeof(mc->r0) * 31);
                        ^~
/home/cosmin/dynamorio/core/unix/signal.c: In function ‘record_pending_signal’:
/home/cosmin/dynamorio/core/unix/signal.c:3720:18: error: storage size of ‘sc_orig’ isn’t known
     sigcontext_t sc_orig;
                  ^~~~~~~
/home/cosmin/dynamorio/core/unix/signal.c:3720:18: error: unused variable ‘sc_orig’ [-Werror=unused-variable]
/home/cosmin/dynamorio/core/unix/signal.c: In function ‘get_sigcontext_from_rt_frame’:
/home/cosmin/dynamorio/core/unix/signal.c:2658:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
/home/cosmin/dynamorio/core/unix/signal.c: In function ‘get_sigcxt_stolen_reg’:
/home/cosmin/dynamorio/core/unix/signal.c:2360:1: error: control reaches end of non-void function [-Werror=return-type]
 }
 ^
cc1: all warnings being treated as errors
make[2]: *** [core/CMakeFiles/dynamorio_static.dir/build.make:1545: core/CMakeFiles/dynamorio_static.dir/unix/signal.c.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:131: core/CMakeFiles/dynamorio_static.dir/all] Error 2
make: *** [Makefile:150: all] Error 2

Not defining _BITS_SIGCONTEXT_H in core/unix/include/sigcontext.h fixes the build for me, but I'm not sure whether it ends up using the wrong structure definitions.

[egrimley]

It seems to me that nothing in DynamoRIO's "sigcontext.h" is used on AArch64. Does it work for you if you add #ifndef AARCH64 just after #define _SIGCONTEXT_H_, and another #endif at the end of the file?

Perhaps that would be a reasonable patch to apply. Then we can leave the conundrum of why DynamoRIO wants to cunningly copy-paste parts of (some version of) glibc's headers, while fiddling with glibc's private macros in an even more cunning attempt to avoid collisions, to the developers on other architectures.

I suspect that this file was added because at some point glibc exported definitions of the kernel's structs, but then later it either stopped exporting those structs or exported a slightly different interface instead, and rather than rename "struct foo" to "struct kernel_foo", or whatever, throughout DynamoRIO's source, someone did this hack.

Perhaps there should be an on-going issue along the lines of "Use private types instead of types exported by the C library", because we don't know that the types exported by the C library (which might not be glibc) are the same as those used by the kernel's ABI. On the other hand, you probably don't want to be too much of a fanatical purist about this because, if you include things like PROT_READ or EINVAL, there are a huge number of things that might theoretically be different in in the C library's API from the kernel's ABI, but almost certainly won't be.

[lgeek]

Hi Edmund. Yes, I can confirm that works for me.

[egrimley]

Thanks. If you get a chance, could you also test 9b101e2 on master? It might have fixed the problem, or it might have made things worse.

[lgeek]

That seems to have fixed it. 9b101e2 builds cleanly for me.

[egrimley]

Thanks for confirming. Though I won't be surprised if similar C library header problems turn up in the future, I'm closing this issue.