by their authors.
This may break builds where others added code relying on these patches,
but please *do not* revert this commit. Instead, we will prepare patches
which fix the failures.
Reverts the following commits:
r168306: "[asan] support x32 mode in the fast stack unwinder. Patch by H.J. Lu"
r168356: "[asan] more support for powerpc, patch by Peter Bergner"
r196489: "[sanitizer] fix the ppc32 build (patch by Jakub Jelinek)"
llvm-svn: 196802
Some linux headers are broken on older kernels.
Instead of depending on the constants and types from such headers directly,
we provide our own definitions and then verify them with compile-time
assertions. This makes the dependency on the headers test-only and would allow
switching to some other way of testing on older kernels, or even disable the
tests as the last resort (after all, kernel interfaces are supposed to be
stable).
llvm-svn: 195427
This header has not been supported at all for the last 2 major OS X releases.
Removed its include and the capture of related symbols.
<rdar://problem/15303348>
llvm-svn: 194841
This change moves everything depending on kernel headers (mostly ioctl types
and ids) into a separate source file. This will reduce the possibility of
header conflict on various platforms (most importantly, older glibc versions).
This change also removes 2 deprecated ioctls, and symbolic ids for other bunch
of ambiguous ioctls (i.e. same id is shared by ioctls with different memory
behavior).
llvm-svn: 188369
First, the reason I came here: I forgot to look at readdir64_r which had
the exact same bug as readdir_r. However, upon applying the same
quick-fix and testing it I discovered that it still didn't work at all.
As a consequence, I spent some time studying the code and thinking about
it and fixed several other problems.
Second, the code was checking for a null entry and result pointer, but
there is no indication that null pointers are viable here. Certainly,
the spec makes it extremely clear that there is no non-error case where
the implementation of readdir_r fails to dereference the 'result'
pointer and store NULL to it. Thus, our checking for a non-null 'result'
pointer before reflecting that write in the instrumentation was
trivially dead. Remove it.
Third, the interceptor was marking the write to the actual dirent struct
by looking at the entry pointer, but nothing in the spec requires that
the dirent struct written is actually written into the entry structure
provided. A threadlocal buffer would be just as conforming, and the spec
goes out of its way to say the pointer to the *actual* result dirent
struct is stored into *result, so *that* is where the interceptor should
reflect a write occuring. This also obviates the need to even consider
whether the 'entry' parameter is null.
Fourth, I got to the bottom of why nothing at all worked in readdir64_r
-- the interceptor structure for dirent64 was completely wrong in that
it was the same as dirent. I fixed this struct to be correct (64-bit
inode and 64-bit offset! just a 64-bit offset isn't enough!) and added
several missing tests for the size and layout of this struct.
llvm-svn: 186109
Chandler Carruth