[PATCH] D28609: [lsan] Enable LSan for x86 Linux.

[Maxim Ostapenko via Phabricator via llvm-commits]

m.ostapenko added inline comments.


================
Comment at: lib/lsan/lsan_interceptors.cc:166
 INTERCEPTOR_ATTRIBUTE
-void *operator new(uptr size) { OPERATOR_NEW_BODY; }
+void *operator new(size_t size) { OPERATOR_NEW_BODY; }
 INTERCEPTOR_ATTRIBUTE
----------------
ygribov wrote:
> m.ostapenko wrote:
> > ygribov wrote:
> > > Why didn't you like uptrs?
> > Because for 32 bit arches uptr doesn't match size_t.
> Hm, I thought it's defined to unsigned long on 32-bits...
Yeah, and size_t is unsigned int. ASan uses size_t as well in new/delete interceptors. I need this just to avoid build errors like:


```
/home/max/src/llvm/projects/compiler-rt/lib/lsan/lsan_interceptors.cc:166:7: error: 'operator new' takes type size_t ('unsigned int') as first parameter
```


================
Comment at: test/lsan/TestCases/use_tls_dynamic.cc:18
+
+__attribute__((noinline)) int Test(int argc, char *argv[]) {
   std::string path = std::string(argv[0]) + "-so.so";
----------------
ygribov wrote:
> m.ostapenko wrote:
> > ygribov wrote:
> > > Looks like a hack to get test passing...
> > Yeah, for x86 the frame for main may contain spilled address for TLS chunk thus leak is not detected. I used the outlining hack to avoid this issue.
> > Do you have any suggestion how we can avoid test failure in another way?
> I'd use XFAIL. The issue sounds quite important (and not really related to your change).
Ok. Right now I don't know how can we properly mitigate the issue (fortunately it affects memory leaks from main for standalone LSan).


Repository:
  rL LLVM

https://reviews.llvm.org/D28609