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: <https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01262.html> Correct struct_kernel_stat_sz for MIPS and don't use <sys/stat.h>.: <https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01263.html> Enable libsanitizer for 32-bit mips*-*-linux*: <https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01264.html> Add gcc port bits for MIPS to support -fsanitize=address: <https://gcc.gnu.org/ml/gcc-patches/2018-03/msg01265.html> > From: Matthew Fortune <matthew.fort...@mips.com> > Date: Fri, 23 Mar 2018 16:19:17 +0000 > Hans-Peter Nilsson <hans-peter.nils...@axis.com> 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 >