This is an archive of the discontinued LLVM Phabricator instance.

[MSan] [MIPS] Adding support for MIPS64
ClosedPublic

Authored by mohit.bhakkad on Oct 22 2014, 5:53 AM.

Details

Summary

Most of the changes are related to mips64 arch.

Diff Detail

Event Timeline

mohit.bhakkad retitled this revision from to [MSan] [MIPS] Adding support for MIPS64.
mohit.bhakkad updated this object.
mohit.bhakkad edited the test plan for this revision. (Show Details)
mohit.bhakkad added reviewers: kcc, petarj, samsonov, eugenis.
mohit.bhakkad set the repository for this revision to rL LLVM.
mohit.bhakkad added subscribers: dsanders, sdkie, Unknown Object (MLST), farazs.
kcc added inline comments.Oct 22 2014, 10:17 AM
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?
If so, just use mips64

lib/sanitizer_common/sanitizer_allocator.h
475

Did you already verify that this actually works?
For a 40-bit address space you may need to use SanitizerAllocator32 instead.

mohit.bhakkad set the repository for this revision to rL LLVM.

This revision resolves mips64 flag related issue

mohit.bhakkad added inline comments.Oct 27 2014, 3:50 AM
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.

kcc added inline comments.Oct 27 2014, 11:15 AM
lib/sanitizer_common/sanitizer_allocator.h
475

How exactly did you verify it?
Did you run any large programs that consume gigs of RAM?
I still doubt this will work.

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?

samsonov edited edge metadata.Oct 28 2014, 9:25 AM

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.

eugenis edited edge metadata.Oct 29 2014, 5:45 PM

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.
The same in msan_allocator.cc and other similar cases.

mohit.bhakkad added inline comments.Nov 9 2014, 10:32 PM
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.

mohit.bhakkad edited the test plan for this revision. (Show Details)
mohit.bhakkad edited edge metadata.
mohit.bhakkad set the repository for this revision to rL LLVM.
mohit.bhakkad edited subscribers, added: slthakur; removed: farazs.

Changes in this revision:

  1. Used SanitizerAllocator32 instead of SanitizerAllocator64 for mips64 as its address space is just 40-bit.
  2. Changed increment for PC in origin tracking w.r.t. mips64.
  3. Put x86_64 in #elif instead of just #else.
samsonov added inline comments.Nov 13 2014, 11:28 AM
lib/msan/msan_report.cc
56 ↗(On Diff #16151)

Evgeniy, do we know the reason why this adjustment is needed? Looks like we'd have to use the inverse of StackTrace::GetPreviousInstructionPc() here.

lib/sanitizer_common/sanitizer_posix.cc
92

Hm? This looks similar to the previous #elif

eugenis added inline comments.Nov 13 2014, 12:34 PM
lib/msan/msan_report.cc
56 ↗(On Diff #16151)

No. I'd like to know why :)

mohit.bhakkad added inline comments.Nov 13 2014, 9:27 PM
lib/sanitizer_common/sanitizer_posix.cc
92

Sorry for my mistake, I didn't realized that it was added in some previous patch.
Any other comments/changes on this revision?

kcc added inline comments.Nov 14 2014, 2:27 PM
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.
At the very least, move it into a separate function near the StackTrace::GetPreviousInstructionPc
but I would like to understand why we need this adjustment here at all.

mohit.bhakkad added inline comments.Nov 16 2014, 10:50 PM
lib/msan/msan_report.cc
58 ↗(On Diff #16151)

I don't know the reason for this adjustment.
I will submit a new revision with a function StackTrace::GetNextInstructionPc in
sanitizer_stacktrace.cc, once http://reviews.llvm.org/D6268 gets commited.

mohit.bhakkad edited the test plan for this revision. (Show Details)
mohit.bhakkad set the repository for this revision to rL LLVM.

Changes in this revision:
Added function StackTrace::GetNextInstructionPc in sanitizer_stacktrace.cc

kcc accepted this revision.Nov 18 2014, 12:58 PM
kcc edited edge metadata.

Looks good.
eugenis, please have one more look and commit if you are ok with this.

This revision is now accepted and ready to land.Nov 18 2014, 12:58 PM

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

samsonov accepted this revision.Nov 19 2014, 1:07 PM
samsonov edited edge metadata.

LGTM

kcc added a comment.Nov 19 2014, 1:08 PM

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?

samsonov closed this revision.Nov 19 2014, 1:43 PM

Landed in r222388.

Now some lucky soul has to update all the docs. :)

Hold on, there hasn't been an LGTM from eugenis@. Why did you land this?

In D5906#14, @eugenis wrote:

I'm OK with this change, but please wait for a comment from Kostya.

^^ 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.

In D5906#36, @kcc wrote:

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?

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.

In D5906#42, @samsonov wrote:
In D5906#14, @eugenis wrote:

I'm OK with this change, but please wait for a comment from Kostya.

^^ here ^^
eugenis@, did I land it too early?

No, it's fine. LGTM.

kcc added a comment.Nov 21 2014, 11:25 AM

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).