[llvm-dev] ASan port for Myriad RTEMS

[Walter Lee via llvm-dev]

I ran our test suite with grain of 8 and 32, and more tests were able to
avoid running out of memory with grain of 32 than 8.  The ones that run out
of memory on 8 but not 32 all failed trying to allocate a large region from
the heap (350M).  I haven't had any tests that run out of memory for other
reasons.

Given that, I will check in the current selected granularity of 32.  I will
try grain 16 and to collect finer grained data when I have a chance.

Thanks,

Walter
On Mon, May 7, 2018 at 2:07 PM Kostya Serebryany <kcc at google.com> wrote:



> On Fri, May 4, 2018 at 7:09 PM Walter Lee <waltl at google.com> wrote:

>> On Fri, May 4, 2018 at 6:21 PM Kostya Serebryany <kcc at google.com> wrote:

>> > On RAM...

>> > You chose the 32-byte shadow granularity to reduce the RAM overhead,
>> > but I am afraid this will actually increase it due to extra alignment
>> requirements,
>> > especially if an average allocation on your typical application is
small.


>> Good point.  I will run our test suite with 8-byte shadow granularity and
>> do some measurements.


> try 16 as well.
> Depending on your typical code and default alignment, I would expect 8 or
16 to be the best.



>> In general, the memory constraint hasn't been as big an issue as I
>> initially thought.  The mitigating factor is that we are focused on unit
>> tests as opposed to running the full blown application.


>> > The pointers are 32-bit, right?
>> > Given how RAM-constrained your environment is, maybe you should
consider
>> something more like HWASAN instead of ASAN.
>> > https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
>> > But you may not have enough address bits. :(

>> Pointers are 32 bits.  Interesting idea, but I agree I don't think we
have
>> enough bits.  Even ignoring the sparsely used lower addresses, DDR +
cache
>> bit leaves us with only 2 bits.

>> Thanks,

>> Walter