Most of the changes are related to mips64 arch.
Diff Detail
Event Timeline
lib/msan/msan.cc | ||
---|---|---|
510 | eugenis@, maybe we should simply drop this code? | |
lib/msan/msan_linux.cc | ||
38 | Why do you use #if defined(__mips64__) && (SANITIZER_WORDSIZE == 64) here and just #if defined(__mips64__) elsewhere? Does mips64 imply SANITIZER_WORDSIZE == 64? | |
lib/sanitizer_common/sanitizer_allocator.h | ||
475 | Did you already verify that this actually works? |
lib/msan/msan_linux.cc | ||
---|---|---|
38 | https://code.google.com/p/android/issues/detail?id=75904 suggests that __mips64 is prevalent than __mips64__ | |
lib/sanitizer_common/sanitizer_allocator.h | ||
475 | Yes, I have verified using both SanitizerAllocator32 and SanitizerAllocator64, which are giving same results. As SizeClassAllocator64 is more efficient, so we are using that. |
lib/sanitizer_common/sanitizer_allocator.h | ||
---|---|---|
475 | How exactly did you verify it? |
How exactly did you verify it?
Did you run any large programs that consume gigs of RAM?
I still doubt this will work.
MIPS is generally used in embedded, which may not require gigs of RAM.
Till now, I have just ran the testcases on mips rpe-100 board, and majority of it are passing.
For real world testing, I have tried MSan on nano editor, which is also working fine.
I will be testing it with some larger application, and will update you with the results.
Any suggestions?
I'm fine with adjusting constants for MIPS you're doing here, but will let Kostya sign this off. I hope you will be able to setup the buildbot, otherwise we can frequently break you.
lib/sanitizer_common/sanitizer_allocator.h | ||
---|---|---|
473 | s/its/it's |
@kcc @samsonov :Thanks for your comments.
To make MSan work on MIPS, there are 2 more patches:
- LLVM code: kShadowMask and kOriginOffset are to be defined for MIPS:
lib/Transforms/Instrumentation/MemorySanitizer.cpp#L123
- Clang code: to enable memory option for mips.
lib/Driver/SanitizerArgs.cpp#L272
I just wanted to ask if I should submit those patches for review, or wait till this one is merged.
I'm OK with this change, but please wait for a comment from Kostya.
I just wanted to ask if I should submit those patches for review, or wait till this one is merged.
Better send them early.
lib/msan/msan.h | ||
---|---|---|
35 | Please change this to #elif defined(x86_64) and an #error if neither is defined. |
lib/msan/msan.h | ||
---|---|---|
35 | I will put x86_64 in #elif, but an extra line for #error will be redundant, as control will never come here, as "memory" option is not enabled in clang driver for those architectures. |
Changes in this revision:
- Used SanitizerAllocator32 instead of SanitizerAllocator64 for mips64 as its address space is just 40-bit.
- Changed increment for PC in origin tracking w.r.t. mips64.
- Put x86_64 in #elif instead of just #else.
lib/msan/msan_report.cc | ||
---|---|---|
56 ↗ | (On Diff #16151) | No. I'd like to know why :) |
lib/sanitizer_common/sanitizer_posix.cc | ||
---|---|---|
92 | Sorry for my mistake, I didn't realized that it was added in some previous patch. |
lib/msan/msan.cc | ||
---|---|---|
510–512 | This code will get deleted with http://reviews.llvm.org/D6268, please wait for it. | |
lib/msan/msan_report.cc | ||
58 ↗ | (On Diff #16151) | I'd prefer not to have #ifdef here. |
lib/msan/msan_report.cc | ||
---|---|---|
58 ↗ | (On Diff #16151) | I don't know the reason for this adjustment. |
Changes in this revision:
Added function StackTrace::GetNextInstructionPc in sanitizer_stacktrace.cc
Thanks @kcc @eugenis @samsonov
Just a gentle reminder, that this patch is dependent on http://reviews.llvm.org/D6146 and http://reviews.llvm.org/D6147
I have one more query, is there is any plan to accept msan32?, if yes I will update whatever changes needed in http://reviews.llvm.org/D5672
I have one more query, is there is any plan to accept msan32?, if yes I will update whatever changes needed in http://reviews.llvm.org/D5672
msan on 32 bit will have very limited applicability due to limited address space.
Remember, the application will have only < 1Gb of RAM available to it.
Supporting msan on 32-bit is an additional maintenance cost with little to not benefit, at least where I see it.
Do you want msan on 32-bit because there are MIPS customers who really need it and can't use 64-bit,
or just for completeness?
^^ here ^^
eugenis@, did I land it too early?
We should update the docs after the change to LLVM instrumentation pass and to Clang driver are in.
We are aware of the limitation of MSan 32bit however there are existing customers of MIPS32 which we think might be potential users of MSAN 32bit.
We are aware of the limitation of MSan 32bit however there are existing customers of MIPS32 which we think might be potential users of MSAN 32bit.
Ok, let's try.
We can not afford to have MIIPS-32 and not have x86-32 because for most developers there is
no way to test on MIIPS-32.
I would ask you to enable MSan on x86-32, make sure that all tests pass,
that check-msan runs the 32-bit tests on x86-64 machines,
that the bots (lab.llvm.org:8011/builders/sanitizer-x86_64-linux and lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/)
run these tests too.
Then we can enable msan on other 32-bit architecture(s).
Please change this to #elif defined(x86_64) and an #error if neither is defined.
The same in msan_allocator.cc and other similar cases.