On Tue, Nov 5, 2013 at 2:24 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > Another problem is internal_syscall casts pointers to > uint64. It doesn't work for x32 since 32-bit pointers are > signed extended to int64. We can need to cast pointer > to uptr first.
Another issue is that it breaks with 2.6.32 kernel headers on x86_64: 219:24: warning: missing initializer for member 'kernel_timeval::tv_sec' [-Wmissing-field-initializers] kernel_timeval tv = {}; and thus bootstrap breaks for me. Richard. > On Tue, Nov 5, 2013 at 3:23 AM, H.J. Lu <hjl.to...@gmail.com> wrote: >> It is a different failure. There are 3 problems: >> >> 1. Hard coded 64-bit registers for pointers in x86-64 asm statements. >> 2. Treat WORD_SIZE == 32 as ia32 for machine state on x86-64. >> 3. On x86-64, assume ia32 FS system calls when LP64 is false. >> >> H.J. >> On Mon, Nov 4, 2013 at 10:35 PM, Konstantin Serebryany >> <konstantin.s.serebry...@gmail.com> wrote: >>> Is this the same failure or different? >>> >>> On Mon, Nov 4, 2013 at 9:49 PM, H.J. Lu <hjl.to...@gmail.com> wrote: >>>> It also breaks x32 build. >>>> >>>> >>>> On Mon, Nov 4, 2013 at 5:48 PM, Konstantin Serebryany >>>> <konstantin.s.serebry...@gmail.com> wrote: >>>>> Hi Peter. >>>>> Does this also mean that asan in llvm trunk is broken for Power? >>>>> We'll need to fix it there too (or, in fact, first). >>>>> >>>>> --kcc >>>>> >>>>> On Mon, Nov 4, 2013 at 4:33 PM, Peter Bergner <berg...@vnet.ibm.com> >>>>> wrote: >>>>>> On Mon, 2013-11-04 at 06:47 -0800, Konstantin Serebryany wrote: >>>>>>> This patch has not been tested on Mac and we generally do not claim >>>>>>> that gcc-asan is supported on Mac. >>>>>>> clang-asan *is* supported on Mac and our bots are green (this patch is >>>>>>> a merge of the sources which are regularly tested on Mac, >>>>>>> but the build procedure is different). >>>>>> >>>>>> The merge from upstream r191666 seems to have broken my >>>>>> powerpc64-linux build. I'm seeing: >>>>>> >>>>>> In file included from >>>>>> /home/bergner/gcc/gcc-fsf-mainline-base/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:21:0: >>>>>> /usr/include/asm/stat.h:31:2: error: ‘ino_t’ does not name a type >>>>>> ino_t st_ino; >>>>>> ^ >>>>>> /usr/include/asm/stat.h:33:2: error: ‘nlink_t’ does not name a type >>>>>> nlink_t st_nlink; >>>>>> ^ >>>>>> /usr/include/asm/stat.h:34:2: error: ‘mode_t’ does not name a type >>>>>> mode_t st_mode; >>>>>> ^ >>>>>> /usr/include/asm/stat.h:39:2: error: ‘uid_t’ does not name a type >>>>>> uid_t st_uid; >>>>>> ^ >>>>>> /usr/include/asm/stat.h:40:2: error: ‘gid_t’ does not name a type >>>>>> gid_t st_gid; >>>>>> ^ >>>>>> /usr/include/asm/stat.h:42:2: error: ‘off_t’ does not name a type >>>>>> off_t st_size; >>>>>> ^ >>>>>> /home/bergner/gcc/gcc-fsf-mainline-base/libsanitizer/sanitizer_common/sanitizer_platform_limits_linux.cc:29:73: >>>>>> error: invalid application of ‘sizeof’ to incomplete type >>>>>> ‘__sanitizer::__old_kernel_stat’ >>>>>> unsigned struct___old_kernel_stat_sz = sizeof(struct >>>>>> __old_kernel_stat); >>>>>> >>>>>> ^ >>>>>> The problem seems to be that the RHEL6 system I am on, the linux/types.h >>>>>> kernel header file doesn't define ino_t like it does on newer systems >>>>>> which leads to the undefined type errors. Digging through the other >>>>>> kernel >>>>>> header files, I'm not really seeing another header file I can include >>>>>> to get it either. :( >>>>>> >>>>>> Peter >>>>>> >>>>>> >>>> >>>> >>>> >>>> -- >>>> H.J. >> >> >> >> -- >> H.J. > > > > -- > H.J.