[llvm-commits] [patch] Change how we handle mandatory unwind tables

Duncan Sands baldrick at free.fr
Tue May 24 23:31:40 PDT 2011


Hi Rafael,

>>> So, what I don't understand now is why do I need a three state then? If keeping
>>> nounwind as is, I only need one bit more to tell me if the user or the ABI
>>> requires me to produce an unwind table entry.
>>
>> the user might have explicitly asked for unwind-tables (using -funwind-tables),
>> or explicitly asked for no unwind-tables (using -fno-unwind-tables), or
>> explicitly asked for neither.  That makes three states :)
>
> Ah. The reason I think we don't need the third one is that the user not
> stating his preference just falls back to the ABI. That is, on x86, the
> following two commands are equivalent
>
> * clang -c foo.c
> * clang -c -fno-asynchronous-unwind-table- foo.c
>
> While on x86_64 the following two are:
>
> * clang -c foo.c
> * clang -c -fasynchronous-unwind-tables foo.c

that's kind of a pity, since it would be nice if at codegen time (i.e. link
time) it was possible to specify -f(no)-asynchronous-unwind-tables and have
this apply to all functions that didn't get an explicit
-f(no)-asynchronous-unwind-tables when first compiled.  If nothing is
specified at codegen time then the ABI default would be used (currently the
front-end is injecting this ABI information; is there any reason that
codegen couldn't do it?).

Ciao, Duncan.



More information about the llvm-commits mailing list