On Fri, Dec 6, 2013 at 2:04 PM, Jakub Jelinek <ja...@redhat.com> wrote: > On Fri, Dec 06, 2013 at 01:52:29PM +0100, Richard Biener wrote: >> > Note that testing still shows some issues, e.g. because the >> > kThreadDescriptorSize change has not been applied. But it at least builds >> > and for many tests works. >> >> What's wrong with just copying the kernel headers 1:1? ISTR that is what >> kernel folks recommend if you use kernel APIs that don't have a glibc >> correspondent. > > Well, for many things that is already the case, sanitizer_common has > apparently it's own __sanitizer_* macros/constants/structures that > are supposed to match kernel ones. The problem is that > the code is comparing them as compile time assertions against the kernel > ones inside of the library code. IMHO that is not a very good idea, much > better would be just say a testcase that would include the sanitizer + > kernel headers, guarded by recent enough LINUX_VERSION_CODE or configure or > similar, so it wouldn't prevent library build on older kernel headers, > the kernel ABI better be stable (only new things added, not size of > structures/magic constants etc. changed from time to time). > > But Kostya is apparently not willing to do that, so this patch provides > a workaround in non-compiler-rt maintained files.
:( >> Of course you then need runtime checks on whether the running kernel >> supports the API. > > Usually not, say if the structures/magic constants etc. are to wrap syscalls > or ioctls etc., if kernel doesn't support those syscalls/ioctls, either > nothing will use those syscalls/ioctls, or if it does, it will fail from the > kernel, worst case you get some diagnostics from pre-syscall/ioctl wrapper, > otherwise the kernel syscall/ioctl will just fail and post-syscall/ioctl > wrapper will do likely nothing at all. Yes, what I meant is that the code needs to expect things to fail dependent on the kernel currently running. Not sure if sanitizer does that. Richard. > Jakub
