Hi Konstantin/Renato,
I did make check all on LLVM on 42 bit VA for the ASAN changes.
Testing Time: 845.30s
********************
Failing Tests (1):
SanitizerCommon-asan :: Linux/getpwnam_r_invalid_user.cc
Expected Passes : 22090
Expected Failures : 129
Unsupported Tests : 420
Unexpected Failures: 1
make[3]: *** [CMakeFiles/check-all] Error 1
make[2]: *** [CMakeFiles/check-all.dir/all] Error 2
make[1]: *** [CMakeFiles/check-all.dir/rule] Error 2
make: *** [check-all] Error 2
'make check-all' failed, bailing out
The test getpwnam_r_invalid_user.cc fails at assert(res == 0);
#include <assert.h>
#include <pwd.h>
#include <signal.h>
#include <stdio.h>
#include <sys/types.h>
#include <unistd.h>
int main(void) {
struct passwd pwd;
struct passwd *pwdres;
char buf[10000];
int res = getpwnam_r("no-such-user", &pwd, buf, sizeof(buf), &pwdres);
assert(res == 0);
assert(pwdres == 0);
return 0;
}
getpwnam_r, here is expected to return 0 but in the Aarch64 test
machine it returns 2 (ENOENT)
man getpwnam_r says
(Snip)
On success, getpwnam_r() and getpwuid_r() return zero, and set
*result to pwd. If no matching password record was found, these
func‐tions return 0 and store NULL in *result. In case of error, an
error number is returned, and NULL is stored in *result.
ERRORS
0 or ENOENT or ESRCH or EBADF or EPERM or ...
The given name or uid was not found
(Snip)
So Planning to drop the assert "assert(res == 0)" from that test case.
does that look good to you?
regards,
Venkat.
On 31 March 2015 at 19:34, Venkataramanan Kumar
<[email protected]> wrote:
> Hi Konstantin/Renato
>
> Remaining failures were due to the way compiler (LLVM) generates code
> for accessing shadow memory.
> It optimizes the code by Oring shadow offset instead of adding it
> thinking that shadow offset is at 1/8 of address space.
>
> On 42 bit VA, default value of 1<<36 is not at 1/8 of address space.
>
> I changed it to
>
> // OR-ing shadow offset if more efficient (at least on x86) if the offset
> // is a power of two, but on ppc64 we have to use add since the shadow
> // offset is not necessary 1/8-th of the address space.
> Mapping.OrShadowOffset = !IsAArch64 && !IsPPC64
> && !(Mapping.Offset & (Mapping.Offset - 1));
>
> Now
>
> Failing Tests (1):
> AddressSanitizer-aarch64-linux :: TestCases/throw_invoke_test.cc
>
> Expected Passes : 414
> Expected Failures : 6
> Unsupported Tests : 129
> Unexpected Failures: 1
>
> Failure is due to missing stdc++, I dont have root permission on that machine.
>
> /usr/bin/ld: cannot find -lstdc++
> clang-3.7: error: linker command failed with exit code 1 (use -v to
> see invocation)
>
> regards,
> Venkat.
>
>
>
>
> On 30 March 2015 at 17:23, Venkataramanan Kumar
> <[email protected]> wrote:
>> Hi Konstantin,
>>
>> On 26 March 2015 at 18:10, Venkataramanan Kumar
>> <[email protected]> wrote:
>>> Hi Konstantin,
>>>
>>> On 26 March 2015 at 03:01, Konstantin Serebryany
>>> <[email protected]> wrote:
>>>> On Wed, Mar 25, 2015 at 10:23 AM, Venkataramanan Kumar
>>>> <[email protected]> wrote:
>>>>> Hi Konstantin/Renato,
>>>>>
>>>>>>> The values that define the location of the shadow are initialized at
>>>>>>> startup,
>>>>>>> so it should not be a problem.
>>>>>>
>>>>>> Excellent!
>>>>>>
>>>>>
>>>>> The Shadow offset, I need to set "1<<39" for Aarch64 (42 bit VA) and
>>>>> 1<<36 for Aarch64 (39 bit VA).
>>>>>
>>>>> In asan_mapping.h, it is defined as static const u64
>>>>> kAArch64_ShadowOffset64 = 1ULL << 36.
>>>>
>>>>
>>>> Why 1ULL << 36 or some other smaller value will not work for both?
>>>>
>>>
>>> On 42 bit VA, I was trying to use 64 bit allocator.
>>>
>>> I have to fix the allocator start and size to 0x10000000000. Other
>>> wise I got the below an assert failures.
>>>
>>> COMPILER_CHECK(kSpaceBeg % kSpaceSize == 0)
>>> COMPILER_CHECK((kRegionSize) >= (1ULL << (SANITIZER_WORDSIZE / 2)))
>>>
>>> Putting shadow offset at 2^39 I got HighMemBeg starting at
>>> 0x10000000000 which also will not interfere with application,
>>> libraries and the stack.
>>>
>>>
>>>>>
>>>>> If I understand correctly, I need to initialize this at startup in
>>>>> both places, compiler-rt/lib/asan and LLVM 's instrumentation place
>>>>> lib/Transforms/Instrumentation/AddressSanitizer.cpp ?
>>>>>
>>>>>>> The values for Allocator64 have to be compile-time constants for
>>>>>>> better performance,
>>>>>>> but Allocator64 is not going to work on 39 (and probably on 42) bits
>>>>>>> anyway.
>>>>>>> We'll need to use Allocator32.
>>>>>
>>>>> For Aarch64 with 42 VA bit I need to turn on Allocator64
>>>> Why?
>>>
>>> ASAN tests passed with 64 bit allocator and with changes I mentioned above.
>>>
>>> So I was assuming we can switch 64 bit allocators when we detect 42
>>> bit VA. But I agree, as we discussed it is not a good thing to do. It
>>> should be uniform across all VA and hence 32 bit allocators should be
>>> default.
>>>
>>>>
>>>>> and for 39
>>>>> bit VA I need to turn on Allocator32.
>>>>> ASAN/TSAN does not work when allocator32 is on for 42bit VA.
>>>>
>>>> Let's not mix asan and tsan.
>>>> What's wrong with asan when "allocator32 is on for 42bit VA"?
>>>
>>> On 42 bit VA, running a simple stack resuse test case. I got this
>>> assert failure.
>>>
>>> ==24573==AddressSanitizer CHECK failed:
>>> /home/venkataramanan.kumar/LLVM/TSAN_port/Source/projects/compiler-rt/lib/sanitizer_common/sanitizer_allocator.h:841
>>> "((res)) < ((kNumPossibleRegions))" (0x3ffb56, 0x80000)
>>>
>>> I am looking it into now,
>>
>> The "kNumPossibleRegions" is defined as per 39 bit VA machine (juno)
>> as 0x8000000000 (max 39 bit VA) / (2^20) = 0x80000.
>>
>> On 42 bit I get stack memory reference at 0x3ffb5600000. The region id
>> computation for the memory is 0x3ffb5600000/(2^20) is "0x3ffb56"
>>
>> Hence the check "((res)) < ((kNumPossibleRegions))" fails.
>>
>> I have to change the SANITIZER_MMAP_RANGE_SIZE to 1 <<42.
>>
>> 0x40000000000 (max 42 bit VA) / (2^20) = 0x3FFFFF
>>
>> Now I still find 76 cases still failing and looking at them.
>>
>>
>>>
>>>
>>>>>
>>>>> So I also need to detect and switch allocator types based on VA.
>>>>>
>>>>>
>>>>> On 25 March 2015 at 22:21, Renato Golin <[email protected]> wrote:
>>>>>> On 25 March 2015 at 16:41, Konstantin Serebryany
>>>>>> <[email protected]> wrote:
>>>>>>> Is it only 39 and 42, or is there a 3-rd option?
>>>>>>
>>>>>> As far as I know, only these two.
>>>>>>
>>>>>>
>>>>>>> The values that define the location of the shadow are initialized at
>>>>>>> startup,
>>>>>>> so it should not be a problem.
>>>>>>
>>>>>> Excellent!
>>>>>>
>>>>>>
>>>>>>> The values for Allocator64 have to be compile-time constants for
>>>>>>> better performance,
>>>>>>> but Allocator64 is not going to work on 39 (and probably on 42) bits
>>>>>>> anyway.
>>>>>>> We'll need to use Allocator32.
>>>>>>
>>>>>> That's our conclusion, too.
>>>>>>
>>>>>> I think the next step is to implement the run-time check for AArch64.
>>>>>>
>>>>>> Thanks for the help!
>>>>>>
>>>>>> cheers,
>>>>>> --renato
>>>
>>> regards,
>>> Venkat,
>>
>> regards,
>> Venkat.
--
You received this message because you are subscribed to the Google Groups
"address-sanitizer" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
