[llvm-dev] ASan port for Myriad RTEMS

[Walter Lee via llvm-dev]

I've finished committing the patch series.  Thanks a lot to Kostya, Vitaly,
Aleksey, and Roland for doing the bulk of the reviews!

Thanks,

Walter
On Fri, May 18, 2018 at 12:06 AM Walter Lee <waltl at google.com> wrote:

> 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