[PATCH] Disable EHABI when -fno-exceptions option is chosen.
eugenis at google.com
Sat Feb 1 11:17:41 PST 2014
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 <renato.golin at linaro.org> wrote:
> On 31 January 2014 15:34, Evgeniy Stepanov <eugenis at google.com> wrote:
>> Why do we even need this flag, and not make the decision in the backend
>> based on -munwind-tables?
> 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.
More information about the cfe-commits