Re: address/leak sanitizer, somebody?
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 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150414161622.gx3...@type.bordeaux.inria.fr
Re: address/leak sanitizer, somebody?
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 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150414160551.gt3...@type.bordeaux.inria.fr
Re: address/leak sanitizer, somebody?
Hi! On Tue, 14 Apr 2015 17:03:46 +0200, Samuel Thibault samuel.thiba...@gnu.org 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, http://darnassus.sceen.net/~hurd-web/open_issues/_san/, 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?
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 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150414150346.gp3...@type.bordeaux.inria.fr
address/leak sanitizer, somebody?
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 -- To UNSUBSCRIBE, email to debian-hurd-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150414130851.ga6...@type.bordeaux.inria.fr