[PATCH] D54590: [compiler-rt][UBSan] Sanitization for alignment assumptions.

[Kamil Rytarowski via Phabricator via llvm-commits]

krytarowski added a comment.

In D54590#1340166 <https://reviews.llvm.org/D54590#1340166>, @lebedev.ri wrote:

> In D54590#1340156 <https://reviews.llvm.org/D54590#1340156>, @krytarowski wrote:
>
> > In D54590#1340152 <https://reviews.llvm.org/D54590#1340152>, @lebedev.ri wrote:
> >
> > > In D54590#1340150 <https://reviews.llvm.org/D54590#1340150>, @krytarowski wrote:
> > >
> > > > Can you test thread_local too?
> > >
> > >
> > > Can you please be more specific? Which test do you want to see?
> >
> >
> > It has been noted that NetBSD's ld.elf_so does not support alignment and there is a workaround in xray: D56000 <https://reviews.llvm.org/D56000>.
> >
> > It would be helpful to test similar (harder to debug) scenarios with UBSan and its tests.
>
>
> I'm guessing you want me to test that this has some ubsan check, correct? https://godbolt.org/z/5xNnBu
>  It currently will not, and **this** check will **not** do it.
>
> And because `@_ZZ18getThreadLocalDatavE10TLDStorage` is declared with `align 64` attribute,
>  even if i emit the check, it will be trivially dropped by middle-end.
>  So i'm not sure how to catch this yet.


I see, pity that it's not expandable right not to TLS allocations.

There is a related workaround in the implementation of TSan for misalignment.


Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D54590/new/

https://reviews.llvm.org/D54590