Renato, I understand what you are trying to achieve, but right now, by enabling EHABI, you effectively disabled it for sanitizers - and even took away the option that we used to enable it back.
We build sanitizer runtimes with exceptions disabled, because otherwise we get a libstdc++ dependency, which is not a good thing. Your last change effectively hardcodes the value of -arm-disable-ehabi option - I can not override it on the command line, because now it is always present in cc1 flags. On Fri, Jan 31, 2014 at 8:31 PM, Renato Golin <[email protected]> wrote: > On 31 January 2014 15:34, Evgeniy Stepanov <[email protected]> wrote: >> >> Why do we even need this flag, and not make the decision in the backend >> based on -munwind-tables? > > > Evgeniy, > > This flag was introduced long ago when the EHABI was experimental (and not > working), so we actually had two flags controlling the emission of landing > pads and exception tables. Not to mess up too much, I've merged them into > the one that is today, but I agree we should merge it again with the other > options that control exception handling. Also, the EHABI is now in a state > of limbo, where it's enabled by default for monitoring and quality > improvements only, and therefore we need the specific disabling flag. > > There is another refactoring that have shown up after enabling the EHABI by > default, is that it's not playing well with Dwarf stack unwinding via CFI > directives (Keith is working on that), so some work will be necessary in > that direction, too. > > I'll have a look on the -munwind-tables option, but I'm guessing it has more > than just EH unwinding. Once EHABI becomes roughly production quality, we'll > have to re-visit all flags and make sure all tools' behaviours (not just > Clang) are consistent with other architectures. > > cheers, > --renato _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
