llvm dev - May 2018 - ASan port for Myriad RTEMS

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180507/6356afd0/attachment.html>

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

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