- User Since
- Sep 20 2016, 10:07 AM (142 w, 6 d)
Jun 16 2018
Jun 8 2018
May 22 2018
May 9 2018
Updated patch, which uses a template with 2 support classes to avoid some code duplication. I must say that I find
#ifndef __GLIBC_PREREQ # define __GLIBC_PREREQ(x, y) 0 #endif
easier to read over the longer sequence of #ifs, and as I said earlier, the proposed
#if defined(__i386__) && (!defined(__GLIBC_PREREQ) || !__GLIBC_PREREQ(2, 27))
is not valid C/C++ if __GLIBC_PREREQ macro is not defined.
Mar 21 2018
Mar 19 2018
glibc 2.27 has added the glob@@GLIBC_2.27 symbols approx. one month after these internal_function changes, so it is closer to that than e.g. trying to parse confstr for glibc 2.27 and later, and is also smaller than trying to parse the confstr string.
Nov 29 2017
Can you or Konstantin please commit it? I don't have write access to llvm repo.
Phabriactor doesn't allow me to update this patch, so I've uploaded it to D40600 instead. If you have a way to update the diff here, please do.
Nov 10 2017
Can you please commit it?
Oct 17 2017
I have no idea how to CC those mailing lists (Change Subscribers doesn't seem to allow those) in this tool (or shall I just mail them normally)?
As for tests, the ones I have for GCC are:
Shouldn't detect_invalid_pointer_pairs=1 be the default? I mean, the user already makes the decision to enable it through a compiler option/parameter and the generated code adds non-zero amount of .text space and some runtime cost, and there is no extra runtime costs for this if code isn't instrumented, so detect_invalid_pointer_pairs=0 by default only causes false assumption that code is error clean.
Besides the patch, we'd like to coordinate on options enabling this in the compilers.
From what I can see, in clang it is currently an experimental asan-detect-invalid-pointer-pair param,
what Martin has implemented is handle it as another kind of sanitization (separate kinds for pointer compare and pointer subtract),
-fsanitize=pointer-subtract or -fsanitize=pointer-compare. One can then do:
-fsanitize=address,pointer-subtract,pointer-compare etc., if address is not specified but one of these is, then
right now we error out. I could imagine pointer-subtract or pointer-compare to be supported even without address
sanitization, where we'd link against libasan and add poisoning/unpoisoning/global variable registration etc., but not
memory dereference checks, the problem is that the compiler then doesn't know if it should do the registration etc.
in kernel-address or user address style.
Jul 13 2017
Could somebody please commit it? Thanks.
Jul 11 2017
Using stack_t in the internal_sigaltstack prototype is problematic, because stack_t is only defined in the *.cc file which includes signal.h through sys/wait.h. But describing what it points to isn't really necessary, the function could be also declared with uptr arguments, or sanitizer_stack_t if we define it independently, etc.
Alternative to using struct res_state * is using res_state, i.e.
res_state statp = (res_state)state;
Feb 17 2017
Feb 15 2017
Feb 10 2017
Note, in theory __builtin_extract_return_addr should be used on all architectures, but not sure if it can't break anything, so I'm proposing to use it for now just on s390 31-bit.
In GCC, the builtin returns something other than its unmodified arguments on:
alpha-vms in certain cases
arm (for 26-bit mode)
mips (always masks off lsb)
hppa (always masks off 2 ls bits)
s390 31-bit mode (always masks off msb)
sparc adds 8 or 12 bytes to it
microblaze adds 8 bytes to it
Feb 9 2017
Shall I upload a new patch with that? What is the process now, can somebody check it in for me?
Updated patch for that.
Feb 8 2017
Oct 17 2016
Defining the builtins directly is certainly not going to work very well.
E.g. GCC libatomic uses:
void libat_load (size_t, void *, void *, int) __asm ("__atomic_load");
void lbat_load (size_t, void *, void *, int); ... typeof (libat_load) export_load __asm ("__atomic_load") __attribute__((alias ("libat_load")));
Sep 20 2016
An interesting question is how to test it upstream.
In theory you could just test it even with C++11, with something like:
Well want to merge all the libsanitizer changes in the next month or two at most, but sure, this can be also desirable for release branch backporting eventually.