[0/4] ASAN for MIPS (o32)

Message ID 201803230249.w2N2n137005421@ignucius.se.axis.com
Headers show
Series
  • ASAN for MIPS (o32)
Related show

Message

Hans-Peter Nilsson March 23, 2018, 2:49 a.m.
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

Comments

Matthew Fortune March 23, 2018, 4:19 p.m. | #1
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