[PATCH 1/2] Always create unwind table entries for functions marked `uwtable`

Rafael Espíndola rafael.espindola at gmail.com
Mon Feb 17 05:28:44 PST 2014


>> With that interpretation, the GCC_except_table should never be
>> modified based on uwtable.
>
> My interpretation of uwtable is based on the change that is reverted in
> my second patch, the documentation in Attributes.h and the existing
> method called "needsUnwindTableEntry", which suggests that in fact an
> entry in the table should be created. If that interpretation is wrong
> and uwtable should just force CFI to be emitted, then this patch isn't
> required, there's already code that checks uwtable to do that.

The UnwindTable in question is for .eh_table, which is what the x86_64
abi requires for unwinding, both by external tools and for c++
exceptions. Suggestions for a better name are welcome.

>> What use case are we not capturing? I.E., what prevents you from just
>> dropping nounwind from a function you want to see in GCC_except_table?
>
> My goal was to restore the invoke->call optimization that was disabled
> by the change I reverted in my second patch, so I tried to fix the
> problem I thought that patch was fixing in a different way. But having
> another look now, that patch actually had no effect on the case where an
> unwind table is created anyway. It only forces the creation of unwind
> tables with empty landing pads that would otherwise be completely
> omitted. Maybe Bill can explain what the reason for that change was.
>
> Björn

Cheers,
Rafael




More information about the llvm-commits mailing list