Re: address/leak sanitizer, somebody?

2015-04-14 Thread Samuel Thibault
Samuel Thibault, le Tue 14 Apr 2015 18:05:51 +0200, a écrit :
> Thomas Schwinge, le Tue 14 Apr 2015 17:59:40 +0200, a écrit :
> > they have intimate knowledge about the operating system kernel
> > they're running on,
> 
> But isn't this needed only for tsan?

More precisely, I see lsan only using internal__exit (only if exitcode
is defined, so it's not too bad not to have it), internal_snprintf and
internal_memset (already implemented), internal_sched_yield (trivial),

Samuel



Re: address/leak sanitizer, somebody?

2015-04-14 Thread Samuel Thibault
Thomas Schwinge, le Tue 14 Apr 2015 17:59:40 +0200, a écrit :
> they have intimate knowledge about the operating system kernel
> they're running on,

But isn't this needed only for tsan?

Samuel



Re: address/leak sanitizer, somebody?

2015-04-14 Thread Thomas Schwinge
Hi!

On Tue, 14 Apr 2015 17:03:46 +0200, Samuel Thibault  
wrote:
> Samuel Thibault, le Tue 14 Apr 2015 15:08:51 +0200, a écrit :
> > For work I've been having a look at -fsanitize in gcc.  It's not as
> > powerful as valgrind, but it should provide very good feedback, and
> > apart from tsan, it seems to be very easy to port to other systems
> > (basically tell the ucontext layout, the rest is mostly glibc-generic
> > actually), could somebody have a look?
> 
> Apparently asan (address sanitizer) is 64bit only, but lsan (memory
> leak) seems to be 32bit too.

When I had a (really quick) look, years ago,
, I
found/declared that »[p]orting these to the Hurd is not a trivial task,
for they have intimate knowledge about the operating system kernel
they're running on, and from a first look they reimplement a lot of glibc
by directly using system calls -- which is basically a no-go on GNU
Hurd«.  Well, maybe not a "no-go", but if my "analysis" is still correct,
we'd need to add a lot of wrapper code, to call back into the "real" libc
(instead of doing system calls).

That said, I'd be very happy about such a port, of course.  Preferably
this should be done directly upstream, that is, in the LLVM repository.
(Which will then be merged in GCC.)


Grüße,
 Thomas


signature.asc
Description: PGP signature


Re: address/leak sanitizer, somebody?

2015-04-14 Thread Samuel Thibault
Samuel Thibault, le Tue 14 Apr 2015 15:08:51 +0200, a écrit :
> For work I've been having a look at -fsanitize in gcc.  It's not as
> powerful as valgrind, but it should provide very good feedback, and
> apart from tsan, it seems to be very easy to port to other systems
> (basically tell the ucontext layout, the rest is mostly glibc-generic
> actually), could somebody have a look?

Apparently asan (address sanitizer) is 64bit only, but lsan (memory
leak) seems to be 32bit too.

Samuel



address/leak sanitizer, somebody?

2015-04-14 Thread Samuel Thibault
Hello,

For work I've been having a look at -fsanitize in gcc.  It's not as
powerful as valgrind, but it should provide very good feedback, and
apart from tsan, it seems to be very easy to port to other systems
(basically tell the ucontext layout, the rest is mostly glibc-generic
actually), could somebody have a look?

Samuel