Re: [PATCH 0/4] ASAN for MIPS (o32)

[Hans-Peter Nilsson]

> Date: Fri, 23 Mar 2018 03:49:01 +0100
> From: Hans-Peter Nilsson 

The patches enabling ASAN for MIPS (32-bit) have now been
committed, on trunk for gcc-9.  I didn't persist pinging release
maintainers for gcc-8, but I'd certainly like to backport them,
if so allowed.

brgds, H-P

Release-manager approval for gcc-8? (was: Re: [PATCH 0/4] ASAN for MIPS (o32))

[Hans-Peter Nilsson]

I'm bringing this to the direct attention of the
release-maintainers, asking for approval for gcc-8.
(If this is in your queue already, then sorry for nagging, but
IIUC you both filter gcc-patches@ traffic heavily.)
All patches are to MIPS-specific code.

libsanitizer:
Add __sanitizer.lock.pad initializer, shutting up a warning:
 
Correct struct_kernel_stat_sz for MIPS and don't use .:
 
Enable libsanitizer for 32-bit mips*-*-linux*:
 
Add gcc port bits for MIPS to support -fsanitize=address:
 

> From: Matthew Fortune 
> Date: Fri, 23 Mar 2018 16:19:17 +

> Hans-Peter Nilsson  writes:
> > All patches are together run through the gcc and g++ test-suites
> > to check ASAN results for mipsisa32r2el-linux-gnu.  As of
> > r258635 those results are on par with those for
> > arm-linux-gnueabihf, so without delay I present the current
> > state.  Maybe it's non-intrusive enough to be ok for gcc-8?
> > MIPS maintainers (and interested party) CC:ed.
> 
> >From a MIPS backend perspective all 4 patches are OK. I've done very
> little to support upstream MIPS over this release so these
> improvements are fantastic. I don't know the detail of asan support
> so am going with the idea that your investigation has got to the
> bottom of the problems; thanks for the detailed explanations.
> 
> I'm not sure I should really approve this for GCC-8 but rather ask
> a global maintainer or Jakub/Richard as release managers given I
> can't commit to do much to support the release and I won't want to
> risk burdening others with a late change.
> 
> > For use with -fsanitize=address, you'll need a non-ancient glibc
> > or equivalent (2002-ish), one that iterates on ELF headers for
> > the EH info at exception time (rather, doesn't call
> > __register_frame_info or __register_frame_info_bases at startup,
> > ending up calling malloc/free) or else Asan will try to
> > instrument the call to free and hang on a lock for eternity (or
> > dies on a signal).  But that's no different than for other
> > ports, AFAIU.
> > 
> > So, ok to commit?
> 
> As above, if a global maintainer is happy then yes.
> 
> Matthew
> 
> > 
> > brgds, H-P
> 

RE: [PATCH 0/4] ASAN for MIPS (o32)

[Matthew Fortune]

Hans-Peter Nilsson  writes:
> All patches are together run through the gcc and g++ test-suites
> to check ASAN results for mipsisa32r2el-linux-gnu.  As of
> r258635 those results are on par with those for
> arm-linux-gnueabihf, so without delay I present the current
> state.  Maybe it's non-intrusive enough to be ok for gcc-8?
> MIPS maintainers (and interested party) CC:ed.

From a MIPS backend perspective all 4 patches are OK. I've done very
little to support upstream MIPS over this release so these
improvements are fantastic. I don't know the detail of asan support
so am going with the idea that your investigation has got to the
bottom of the problems; thanks for the detailed explanations.

I'm not sure I should really approve this for GCC-8 but rather ask
a global maintainer or Jakub/Richard as release managers given I
can't commit to do much to support the release and I won't want to
risk burdening others with a late change.

> For use with -fsanitize=address, you'll need a non-ancient glibc
> or equivalent (2002-ish), one that iterates on ELF headers for
> the EH info at exception time (rather, doesn't call
> __register_frame_info or __register_frame_info_bases at startup,
> ending up calling malloc/free) or else Asan will try to
> instrument the call to free and hang on a lock for eternity (or
> dies on a signal).  But that's no different than for other
> ports, AFAIU.
> 
> So, ok to commit?

As above, if a global maintainer is happy then yes.

Matthew

> 
> brgds, H-P

[PATCH 0/4] ASAN for MIPS (o32)

[Hans-Peter Nilsson]

All patches are together run through the gcc and g++ test-suites
to check ASAN results for mipsisa32r2el-linux-gnu.  As of
r258635 those results are on par with those for
arm-linux-gnueabihf, so without delay I present the current
state.  Maybe it's non-intrusive enough to be ok for gcc-8?
MIPS maintainers (and interested party) CC:ed.

For use with -fsanitize=address, you'll need a non-ancient glibc
or equivalent (2002-ish), one that iterates on ELF headers for
the EH info at exception time (rather, doesn't call
__register_frame_info or __register_frame_info_bases at startup,
ending up calling malloc/free) or else Asan will try to
instrument the call to free and hang on a lock for eternity (or
dies on a signal).  But that's no different than for other
ports, AFAIU.

So, ok to commit?

brgds, H-P