_______________________________________________
LLVM Developers mailing list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
Hi Ivan,
Thanks for posting this; I'm excited by this proposal - if we can
get this kind of support in without making the implementation
non-trivially-harder to maintain, that would be a positive
development. As Sean mentioned, I did something along these lines
to adapt ASan to the IBM BG/Q - an HPC system that uses a
lightweight operating system. On the BG/Q, the lightweight
operating system does support virtual memory for some
special-purpose mappings, but it does not support mapping
unreserved pages (i.e. MAP_NORESERVE is not supported, and this
functionality is not supported any other way). As a result, the
mechanism that the sanitizers use to cover the complete address
space using shadow memory - by mapping a large region of
unreserved pages - won't work in this environment. Systems without
virtual memory at all will obviously have the same problem: All
shadow memory must be physically backed. I'll also mention that
many normal Linux HPC environments are configured with overcommit
turned off, and I believe that using the sanitizers in such
environments would also currently not work.
Because all shadow memory must be physically backed, it must be
allocated judicially, and the mapping process might need to be
more complicated than a simple shift/offset. On the BG/Q, there
were a few distinct regions of virtual memory that needed to be
mapped into a single shadow region in the part of the address
space where heap allocations could be made - as a result, I used a
more-complicated mapping function.
In this light, I'm trying to understand your proposal. I see that you're proposing to add support for some kind of additional translation scheme between virtual addresses and physical addresses, but I'm not exactly sure how you propose to use them. It might help if you were to provide some hypothetical implementation of these translations for a simple system so that we can understand the usage model better. I'd also like to better understand how the instrumentation works; if the mapping always replaced by these __asan_mem_to_vshadow/__asan_mem_to_pshadow calls?
Finally, I recommend that we layer this support so that we have:
[regular system] -> [system without (sufficient) unreserved pages] -> [system without any mmu]
I'd like a clear explanation of how these last two differ. It looks like you have support for manually zeroing pages for the last category. Please explain exactly how this scheme works.
Thanks,
Hal
_______________________________________________ LLVM Developers mailing list llvm...@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-- Hal Finkel Lead, Compiler Technology and Programming Languages Leadership Computing Facility Argonne National Laboratory