This is an archive of the discontinued LLVM Phabricator instance.

[asan] [mips] added support of asan for mips64/mips64el
ClosedPublic

Authored by sdkie on Oct 29 2014, 5:24 AM.

Details

Summary

just done few architecture dependent code
Corresponding LLVM patch - http://reviews.llvm.org/D6165

Diff Detail

Event Timeline

sdkie updated this revision to Diff 15545.Oct 29 2014, 5:24 AM
sdkie retitled this revision from to [asan] [mips] added support of asan for mips64/mips64el.
sdkie updated this object.
sdkie edited the test plan for this revision. (Show Details)
sdkie added reviewers: kcc, samsonov, petarj.
sdkie set the repository for this revision to rL LLVM.
sdkie added subscribers: dsanders, mohit.bhakkad, slthakur.
sdkie added a subscriber: Unknown Object (MLST).
samsonov edited edge metadata.Oct 29 2014, 9:48 AM

Again, I'll let Kostya sign this off. I'm generally fine with this change as long as it really fixes MIPS and you plan to support MIPS port.

kcc added inline comments.Oct 30 2014, 10:18 AM
lib/asan/asan_allocator.h
107 ↗(On Diff #15545)

Is this enough?
As I've asked in http://reviews.llvm.org/D5906, did you verify that this works on
applications that allocate 8Gb of RAM with the same size class?
Or mips machines are not expected to be used with that much RAM?
What is the maximal amount of physical RAM in a mips machine for a foreseeable future?

lib/sanitizer_common/sanitizer_printf.cc
115

I'd like to move this logic to sanitizer_common/sanitizer_platform.h.

Define something like SANITIZER_POINTER_FORMAT_LENGTH there and
please use FIRST_32_SECOND_64

dsanders added inline comments.Nov 3 2014, 6:24 AM
lib/asan/asan_allocator.h
107 ↗(On Diff #15545)

As I've asked in http://reviews.llvm.org/D5906, did you verify that this works on applications that allocate 8Gb of RAM with the same size class?
Or mips machines are not expected to be used with that much RAM?
What is the maximal amount of physical RAM in a mips machine for a foreseeable future?

I can't answer the 'Is this enough?' question but at the moment the biggest machines we have available to test on have 8GB RAM. It seems reasonable to predict that there will be >32GB machines in the not too distant future though.

One other thing to mention is that I've just found out that MIPS64r1 is limited to 36-bit physical addresses (64GB). MIPS64r2 added an extension to provide (up to) 59-bit physical addresses. On both architectures, there is a 64-bit virtual address space of which half is for the kernel and half is for user applications.

kcc added inline comments.Nov 3 2014, 10:59 AM
lib/asan/asan_allocator.h
107 ↗(On Diff #15545)

The way SanitizerAllocator64 is designed it will not work with 36-bit physical addresses.
It will appear to work on small tests, but as soon as you try to allocate Gigs of RAM with e.g. 32-byte chunks it will run out of space.
So, for 36-bit space just use SanitizerAllocator32

59-bit physical addresses should be more than enough to use SanitizerAllocator64

sdkie updated this revision to Diff 15855.Nov 6 2014, 4:50 AM
sdkie edited edge metadata.

added SANITIZER_POINTER_FORMAT_LENGTH variable

sdkie added a comment.Nov 6 2014, 5:27 AM

@kcc: As mentioned here[1], whether 16TB of memory is must for asan64 ?
Because test-cases in compiler-rt are working fine.
Now I am planning to build some big application with asan which require GBs of memory.

[1] http://clang.llvm.org/docs/AddressSanitizer.html#limitations

kcc edited edge metadata.Nov 6 2014, 11:30 AM
In D6024#13, @kumarsukhani wrote:

@kcc: As mentioned here[1], whether 16TB of memory is must for asan64 ?

16Tb is the limit for the 47-bit address space in x86_64 -- asan requires that much AS for the shadow.
It also requires 4Tb for the allocator, so on x86_64 the current requirement is 20Tb.

With another address space the limits will be different.

Because test-cases in compiler-rt are working fine.
Now I am planning to build some big application with asan which require GBs of memory.

No need to try a large app.
Write a test that allocates (and does not deallocate) 32-byte chunks in an infinite loop and see how much RAM it can allocate.

[1] http://clang.llvm.org/docs/AddressSanitizer.html#limitations

sdkie added a comment.Nov 7 2014, 12:35 AM

@kcc: with top command I can see that address sanitized application can allocate VIRT(virtual memory) upto 1TB before exiting .

sdkie updated this object.Nov 7 2014, 6:55 AM
sdkie edited edge metadata.
kcc added a comment.Nov 7 2014, 11:15 AM
In D6024#15, @kumarsukhani wrote:

@kcc: with top command I can see that address sanitized application can allocate VIRT(virtual memory) upto 1TB before exiting .

This is not what I suggested. Please run the following program:
#include <stdio.h>
volatile void *sink;
int main() {

const size_t kSize = 24;
for (size_t i = 0; ; i++) {
  if ((i & (i - 1)) == 0)
    printf("Allocated %zd chunks of %zd bytes, total %zd Mb\n", 
           i, kSize, (i * kSize) >> 20);
  char *x = new char[kSize];
  x[i % kSize] = 42;
  sink = x;
}

}

clang++ -fsanitize=address malloc_loop.cc && ./a.out

With the current settings on x86_64 it will exhaust all RAM on my machine before dying.
If I set kAllocatorSize to 0x4000000000ULL (minimal allowed) the program will fail like this:
...
Allocated 33554432 chunks of 24 bytes, total 768 Mb
Allocated 67108864 chunks of 24 bytes, total 1536 Mb
AddressSanitizer: Out of memory. Dying. The process has exhausted 4096MB for size class 48.

You don't want you program to die after allocating ~3Gb of memory.

Yet again, SanitizerAllocator64 is not designed to support 36-bit address space, just use SanitizerAllocator32

sdkie added a comment.EditedNov 10 2014, 1:29 AM

I got same output as you posted above. I tested it on mips64.

...
Allocated 16777216 chunks of 24 bytes, total 384 Mb
Allocated 33554432 chunks of 24 bytes, total 768 Mb
Allocated 67108864 chunks of 24 bytes, total 1536 Mb
AddressSanitizer: Out of memory. Dying. The process has exhausted 4096MB for size class 48.

kcc added a comment.Nov 11 2014, 2:59 PM
In D6024#18, @kumarsukhani wrote:

I got same output as you posted above. I tested it on mips64.

...
Allocated 16777216 chunks of 24 bytes, total 384 Mb
Allocated 33554432 chunks of 24 bytes, total 768 Mb
Allocated 67108864 chunks of 24 bytes, total 1536 Mb
AddressSanitizer: Out of memory. Dying. The process has exhausted 4096MB for size class 48.

Which proves my point. Don't use SanitizerAllocator64 unless you have at least ~46 bits of address space.
Check SANITIZER_CAN_USE_ALLOCATOR64 in sanitizer_common/sanitizer_platform.h

sdkie updated this revision to Diff 16076.Nov 12 2014, 1:42 AM

using SanitizerAllocator32 instead of SanitizerAllocator64 for mips64 as its address space is just 40-bit

sdkie added a comment.Nov 12 2014, 4:14 AM

The output of malloc_loop.cc:
...
Allocated 16777216 chunks of 24 bytes, total 384 Mb
Allocated 33554432 chunks of 24 bytes, total 768 Mb
Allocated 67108864 chunks of 24 bytes, total 1536 Mb
Killed

kcc accepted this revision.Nov 12 2014, 10:16 AM
kcc edited edge metadata.

LGTM

This revision is now accepted and ready to land.Nov 12 2014, 10:16 AM
kcc closed this revision.Nov 12 2014, 10:23 AM

r221800.

lib/sanitizer_common/sanitizer_platform.h
115

This needs to be "8,12", not "12,8"
Please make sure your patches pass testing (check-all) on x86_64 Linux:

Sorry for that mistake.
I will make sure my patch doesn't break anything on x86_64.