Message ID | 201803230249.w2N2n137005421@ignucius.se.axis.com |
---|---|
Headers | show |
Series | ASAN for MIPS (o32) | expand |
Hans-Peter Nilsson <hans-peter.nilsson@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