On Tue, Nov 5, 2013 at 10:45 AM, Jakub Jelinek <ja...@redhat.com> wrote: > On Tue, Nov 05, 2013 at 10:17:09AM -0800, Evgeniy Stepanov wrote: >> On Tue, Nov 5, 2013 at 10:07 AM, Peter Bergner <berg...@vnet.ibm.com> wrote: >> > On Tue, 2013-11-05 at 09:57 -0600, Peter Bergner wrote: >> >> On Tue, 2013-11-05 at 08:19 +0100, Jakub Jelinek wrote: >> >> > Note, not even glibc itself includes <asm/stat.h>, so the chances of >> >> > that >> >> > header actually working for you are low. glibc instead just defines the >> >> > structures itself for each of the architectures. >> >> >> >> I have to agree, including kernel header files is always frowned upon >> >> and very risky. Jakub, do you think we should be doing the same thing >> >> here that glibc does, namely having libsanitizer defining its own >> >> structures? >> > >> > One other problem is the use of __old_kernel_stat in the libsanitizer >> > sources. The PPC64 kernel was created after the change to the current >> > stat, so it doesn't define __old_kernel_stat since it never had one. >> >> In fact, we do define our own structures. Kernel headers are limited >> to one or two files just to verify that our definitions are binary >> compatible. >> >> __old_kernel_stat issue must be solvable with a reasonable amount of #ifdefs. > > Perhaps that verification should be done instead just by testing this, > say by calling both libasan stat* and corresponding glibc stat* on the same > files and comparing? You can do the latter through say dlsym/dlvsym. > > Some kernel headers are really better to be avoided, because, as you could > already partly see now or in the past, some of them were never really > properly tested to be usable from userland, or at least not in every distro > and it's version out there. Kernel headers used by glibc itself internally > have a higher chance of working than others.
This way we can't test kernel interfaces that are not used in glibc, like linux aio. Most of our team is travelling, and we won't be able to submit a proper fix until next week. Is this blocking anyone? Are you OK with disabling broken parts with #ifdefs for now? Most of this is used in the interceptors, and they can be disabled on an individual basis.
