Re: toolchain/54090: gcc -fsanitize=address creates an unusable binary on amd64

[Kamil Rytarowski <n54%gmx.com@localhost>]

The following reply was made to PR toolchain/54090; it has been noted by GNATS.

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: toolchain/54090: gcc -fsanitize=address creates an unusable
 binary on amd64
Date: Sun, 31 Mar 2019 14:06:00 +0200

 On 31.03.2019 13:45, Alexander Nasonov wrote:
 > The following reply was made to PR toolchain/54090; it has been noted by=
  GNATS.
 >
 > From: Alexander Nasonov <alnsn%yandex.ru@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
 > 	netbsd-bugs%netbsd.org@localhost, alnsn%netbsd.org@localhost
 > Subject: Re: toolchain/54090: gcc -fsanitize=3Daddress creates an unusab=
 le
 >  binary on amd64
 > Date: Sun, 31 Mar 2019 12:43:56 +0100
 >
 >  Kamil Rytarowski wrote:
 >  >  If this is enough, I propose to disable detect_leaks unconditionally=
  and
 >  >  leave it for future.
 >
 >  Disabling it silently isn't ideal because some people may falsely
 >  assume that their software is leak free.
 >
 
 I propose to stop claiming LSan support at this point and disable it in
 the ASan code (undef CAN_SANITIZE_LEAKS).
 
 >  In a typical setup (when /proc is mounted with nolinux), it doesn't
 >  hang but prints some useful hints:
 >
 >   $ ./a.out
 >   =3D=3D373=3D=3DCan't open /proc/6440/task for reading.
 >   =3D=3D6440=3D=3DLeakSanitizer has encountered a fatal error.
 >   =3D=3D6440=3D=3DHINT: For debugging, try setting environment variable =
 LSAN_OPTIONS=3Dverbosity=3D1:log_threads=3D1
 >   =3D=3D6440=3D=3DHINT: LeakSanitizer does not work under ptrace (strace=
 , gdb, etc)
 >
 >  Can we add another hint here about detect_leaks?
 >
 
 At this point it's premature to work on LSan in my opinion, first we
 must accomplish all ptrace(2) work.
 
 Later I plan to add a dedicated kernel syscall for StopTheWorld() and so
 make it compatible with strace/gdb etc, and not to reuse the horrid
 Linux-style code there.
 
 >  --
 >  Alex
 >
 >