[PATCH] Disable EHABI when -fno-exceptions option is chosen.

[Evgeniy Stepanov]

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 <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?
>
>
> 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